Vizualizace dat ze štoly Josef Data visualisation from Josef gallery

(1)

TECHNICKÁ UNIVERZITA V LIBERCI

Fakulta mechatroniky, informatiky a mezioborových studií

Studijní program: B2612 – Elektrotechnika a informatika

Studijní obor: 2612R011 – Elektronické informační a řídicí systémy

Vizualizace dat ze štoly Josef

Data visualisation from Josef gallery

Bakalářská práce

Autor: Viktor Dlouhý

Vedoucí práce: Ing. Miloš Hernych Konzultant: Ing. Radek Srb

V Liberci 15. 5. 2012

(2)

Prohlášení

Byl jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje zákon č. 121/2000 Sb., o právu autorském, zejména § 60 – školní dílo.

Beru na vědomí, že Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé bakalářské práce pro vnitřní potřebu TUL.

Užiji-li bakalářskou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tomto případě má TUL právo ode mne požadovat úhradu nákladů, které vynaložila na vytvoření díla, až do jejich skutečné výše.

Bakalářskou práci jsem vypracoval samostatně s použitím uvedené literatury a na základě konzultací s vedoucím bakalářské práce a konzultantem.

15. 5. 2012

(3)

Abstrakt

Tato práce řeší návrh programu pro vzdálený přístup k datům a jejich vizualizaci na zařízeních s operačním systémem Android. Zvlášť jsou analyzovány komunikační možnosti PLC Tecomat Foxtrot a především se zabývá využitím webového serveru, který je podporován na všech zařízeních, jež aplikace využívá pro sběr dat.

Práce dále popisuje některé zajímavosti operačního systému Android, na který byla aplikace navrhována.

Klíčová slova

Android, Tecomat Foxtrot, Java, webový server, HTPP komunikace, vizualizace

Abstract

This thesis is dealing with design of application specified by possibility of remote data access and their visualization on Android operating system equipped devices. Communication options of Tecomat Foxtrot are analyzed, mainly possibilities of pre-installed web server.

Project also contains some interesting topics about operating system Android, on which is application designed.

Keywords

Android, Tecomat Foxtrot, Java, web server, HTTP communication, visualization

(4)

Obsah

1. Úvod ... 6

2. Seznámení s tématikou ... 7

2.1. Motivace ... 7

2.2. Experimentální štola Josef ... 7

3. Komunikační možnosti PLC Tecomat Foxtrot ... 9

3.1. Obecně ... 9

3.2. Web server ... 9

3.3. Epsnet ... 10

3.4. PLCCOmS ... 11

4. Operační systém Android ... 12

4.1. Všeobecně ... 12

4.2. Verze OS Android ... 12

4.3. Programování pro Android ... 13

5. Návrh programu ... 14

5.1. Vymezení cílů ... 14

5.2. Grafický návrh aplikace ... 15

5.3. Odposlech HTTP komunikace ... 17

6. Implementace ... 21

6.1. Zajímavosti v Androidu ... 21

6.2. Obecné koncepce aplikace ... 25

(5)

6.3. Programová koncepce aplikace ... 27

6.4. Struktura zdrojového kódu ... 29

6.5. Ukázky ze zdrojového kódu ... 30

6.5.1. TecoConnector ... 30

6.5.2. FileManager ... 31

6.5.3. DialogAsyncWaiting ... 33

7. Závěr ... 35

Seznam použité literatury ... 36

Seznam použitých obrázků ... 37

Seznam zkratek ... 38

Přílohy ... 39

(6)

1. Úvod

Cílem práce je návrh programu pro operační systém Android, který dokáže přehledně zobrazit strukturovaná data, jejichž sběr probíhá plně automaticky na vzdáleném pracovišti TUL.

Práce se nejdříve zabývá seznámením s tématikou a okolnostmi samotné práce, dále je rozvedena problematika komunikačních možností PLC Tecomat Foxtrot a seznámení s operačním systémem Android. Praktická část popisuje návrh programu, analýzu zadání a vymezení cílů, a poté popis některých zásadních programových či obecných koncepcí, které navržená aplikace používá.

(7)

2. Seznámení s tématikou 2.1. Motivace

Moji snahou bylo vytvořit víceúčelový program, jenž umožní komukoliv (nejen pracovníkovi TUL) se připojit na PLC Tecomat, ve kterém probíhá sběr dat.

Motivací byla realizace komunikace mezi vzdáleným zařízením PLC a přenosným tabletem přes TCP/IP, kterou ještě nikdo programově neimplementoval, větší porozumění nově představených funkcí v aplikačním rozhraní OS Android a možnost vytvořit prospěšnou a funkční aplikaci.

Jasným přínosem pro řešitele je porozumění Tecomatům především v komunikačních možnostech a získat zkušenosti s vývojem softwaru pro OS Android.

2.2. Experimentální štola Josef

Vzdáleným pracovištěm je v tomto případě experimentální štola Josef. Štola slouží jako podzemní výukové středisko. Ražba štoly souvisela s geologickým průzkumem zlatonosných ložisek.

Obrázek 1 – areál štoly Josef [1]

Ve štole probíhá několik experimentů v režii TUL. První experiment se zabývá zkoumáním žulového masivu. Ten je lokálně ohříván topnými spirálami, které jsou řízeny za pomoci PLC Tecomat pulzně šířkovou modulací. V definovaných vzdálenostech od zdroje tepla jsou umístěny snímače teploty. PLC po daných intervalech archivuje aktuální stav snímačů do souboru ve formátu CSV na SD kartu.

(8)

Druhý experiment měří výšku hladiny vody ve dvou šikmých vrtech. Vrty jsou zhruba 4 metry hluboké, pomocí tlakových snímačů je možné sledovat výšku hladiny, čerpadlem je pak možné ovládat případné odčerpávání vody. Experiment má za úkol prověřit puklinové proudění vody. Vše je řízeno z PLC a naměřené hodnotu jsou stejně jako v prvním experimentu ukládány do souboru ve formátu CSV.

CSV (comma separated values) je textový datový formát, kde jsou hodnoty odděleny standardně čárkou, často se ale využívají i jiné oddělovače jako tabulátor, středník či pomlčka. Soubor je tvořen řádky, jež jsou vždy odděleny enterem (respektive v ASCII hodnotou 16, nazývanou line feed).

(9)

3. Komunikační možnosti PLC Tecomat Foxtrot 3.1. Obecně

Zadáním práce je vizualizovat data archivovaná zařízením PLC Foxtrot od firmy Teco.

Tecomaty nenabízí jednoduchý a běžně přístupný prostředek pro strojové získávání těchto dat. Zařízení mohou být na dálku obsluhována pomocí web serveru, je možné měnit jednotlivé registry pomocí protokolu Epsnet a nebo prostřednictvím PC získávat informace o proměnných a souborech pomocí PLCComS.

3.2. Web server

Na každém PLC řady Tecomat Foxtrot může běžet web server. Web server funguje jako neupřednostňovaný proces zařízení. Úkolem PLC je především řídit, proto činnost web serveru je závislá na vytíženosti zařízení. Pokud je na webové rozhraní odesláno příliš mnoho dotazů, jsou vyřizovány až po prioritních řídicích činnostech PLC.

Obrázek 2 – ukázka webového rozhraní používaného pro experimenty v Josefu

(10)

Web server je tedy vrstva, kterou nelze považovat za prioritní. Úkolem web serveru je pouze snadná vizualizace dat či ovládání některých proměnných. Obecně lze i omezit počet aktuálně přihlášených uživatelů tak, aby to zbytečně nezatěžovalo řídící procesy.

Prostřednictvím webového serveru je možné přistupovat k datům uložených na SD kartě PLC.

Pokud je IP adresa PLC 192.168.1.1 a soubor na kartě uložený pod názvem test1.csv, je možné soubor získat pomocí GET metody v podobě dotazu na adresu 192.168.1.1/test1.csv.

Pokud jsou soubory uloženy v podadresáři SD karty (nejsou v kořeni), je vypsán podobný souborový list, jako to bývá u běžných web serverů založených na otevřeném projektu Apache.

Obrázek 3 – ukázka možného výpisu souborů na web serverech Apache [2]

3.3. Epsnet

Epsnet je všeobecný aplikační protokol, implementovaný na několika transportních i fyzických vrstvách PLC Tecomat Foxtrot. Epsnet je podporován na fyzické vrstvě RS232, RS485 a vrstvě typu Ethernet. Jako nejvhodnější pro účely této práce se hodí jeho implementace na transportní vrstvě UDP, která je všeobecně používaná na internetu v součinnosti se síťovou vrstvou IP.

Epsnet je protokol založený na principu „dotaz – odpověď“. Pomocí něj je možné získat data z registrů, zapisovat data do registrů, zapisovat řídící slova (restartovat či vypínat PLC).

Implementace tohoto protokolu by vytvořila mocný klientský program, jenž by dokázal v reálném čase zobrazovat aktuální naměřené hodnoty, či stav PLC a mnoho dalších věcí.

Bohužel se tento protokol příliš nehodí pro řešení této práce. Pomocí Epsnetu by bylo možné archivovat data, avšak nebylo by možné zobrazovat již archivovaná data na PLC.

(11)

3.4. PLCCOmS

Tento komunikační server poskytuje spojení mezi klientským zařízením a PLC. Komunikace je řešena stylem „dotaz – odpověď“. Příkazy jsou textového typu. Server komunikuje s PLC pomocí protokolu Epsnet, klient komunikuje se serverem pomocí aplikačního protokolu Telnet na TCP/IP. Telnet je velice starý protokol, který byl vyvinut roku 1969. Nepoužívá žádné bezpečnostní opatření, proto není úplně vhodné ho používat v síti internet.

PLCComS je uzavřené řešení od společnosti Teco, které je napsané v C/C++ a zkompilované na platformu Windows. Tento server je možné chápat jako zjednodušení protokolu Epsnet a jeho převedení do textové podoby, jeho funkce jsou omezené.

Obrázek 4 – komunikační schéma pro PLCComS [3]

Celá koncepce PLCComS serveru je rovněž pro řešení zadání nevhodné. Jak z popisu vyplývá, pro funkci serveru je nutné mít dedikované PC s OS Windows, se kterým by vzdálené mobilní zařízení komunikovalo. To však nepřipadá v úvahu, tablet by měl být schopný komunikovat s PLC sám a nezávisle.

(12)

4. Operační systém Android 4.1. Všeobecně

Android je mladý, rychle se rozvíjející operační systém pro mobilní zařízení. Jeho první verze byla představena 23. září 2008. Základem je linuxové jádro verze 2.6, tato nejnižší vrstva systému zajišťuje základní operace jako například práci s pamětí nebo řízení procesů. Na něm je postavena řada knihoven (SQL, OpenGL, WebKit, a další) a především Dalvik Virtual Machine. Tento virtuální stroj slouží ke spuštění aplikací předkompilovaných pro Android.

Dalvik je odlišný od klasické Java Virtual Machine. Dalvik je napsaný pro mobilní zařízení a dokáže zpracovávat Android verzi byte kódu. Při jeho vývoji se dbalo hlavně na nízké paměťové nároky. Na Dalviku je založen běh Androidu, v Javě je totiž napsaný celý aplikační framework, zároveň celé grafické rozhraní a téměř každá aplikace. Je možné však psát i v nativním jazyku tedy C/C++.

4.2. Verze OS Android

Operační systém Android se od svého uvedení dost proměnil. Původně byl tento systém určen hlavně pro mobilní telefony. Přelomovou verzí byl Android 3.0 Honeycomb, který byl jako první optimalizovaný na tablety. V tu dobu se na telefony nasazovala ještě verze Android 2.3 Gingerbread. Tyto dvě poměrně dost odlišné varianty byly následně sjednoceny univerzální verzí Android 4.0 Ice Cream Sandwich, který může být plnohodnotně nasazen jak na tablety, tak na mobilní telefony.

Tabulka 1 – seznam verzí OS Android, podle [4]

Jméno API level

4. Ice Cream Sandwich 14-15 1.0%

3. Honeycomb 11-13 3.4%

2.3 Gingerbread 9-10 58.6%

2.2 Froyo 8 27.8%

2.0, 2.1 Eclair 7 7.6%

1.6 Donut 4 1.0%

1.5 Cupcake 3 0.6%

(13)

4.3. Programování pro Android

Pro Android se tvoří aplikace především v Javě. Android API však neobsahuje to samé jako Java API, zhruba čtyřicet procent je složeno z vybraných prvků Java API a zbytek je úplně nový.

Jako vývojové prostředí je přímo podporováno Eclipse IDE, což je otevřené multiplatformní modulární prostředí původně vytvořené společností IBM. Pro tvorbu programu je nutné mít na počítači nainstalované ještě Android SDK a speciální plugin pro Eclipse podporující Android projekty.

(14)

5. Návrh programu 5.1. Vymezení cílů

Při analýze zadání vznikl seznam požadavků, které by aplikace měla implementovat nebo řešit.

 Čtení CSV souborů a vykreslování grafů

Aplikace musí být schopná zobrazit jakýkoliv typ CSV souboru, měla by umět se soubory pracovat, umožnit je filtrovat a případně editovat.

 XML serializace

Pro uchovávání dat je nutná serializace a deserializace dat. Soubory CSV nejsou vhodné pro serializaci, protože jejich formátování je příliš jednoduché a struktura u velkých souborů nepřehledná. XML se jeví jako nejvhodnější jednoduchý a přehledný typ formátování. XML je univerzální přirozený jazyk, do kterého lze ukládat jakákoliv data. XML umožní i případné zpracování projektů vytvořených navrhnutou aplikací i na jiných platformách jinými programy.

 Přihlašovaní na Teco web server pomocí HTTP pro stahování dat z SD karty

Zásadní pro tuto práci je vytvořit funkční způsob přihlašování na PLC Tecomat Foxtrot. Přihlašování by mělo fungovat uvnitř aplikace. Není vhodné, aby uživatel musel otevírat prohlížeč a v nějaké externí aplikaci stahovat archivovaná data.

 Jednoduchý správce souborů

Aplikace by měla obsahovat jednoduchého správce souborů, jenž umožní přehlednou manipulaci s podkladovými daty ve formátu CSV. Dále umožní prohlížet vnitřní úložiště, načítání souborů a otevírání projektů.

 Optimalizace na telefony a tablety

Aplikace by měla být použitelná na široké škále tabletů, případně i mobilních telefonů.

(15)

 Implementace protokolu Epsnet pro zobrazování dat v reálném čase

Jako možné řešení se jeví i implementace protokolu Epsnet, který umožní zobrazovat hodnoty v reálném čase.

 Projekty AndroidPlot a SimpleXML

AndroidPlot je otevřený projekt, který je napsaný v Javě a umožňuje zobrazovat grafy.

SimpleXML se stará o serializaci a deserializace do/z XML.

5.2. Grafický návrh aplikace

Aplikace je navržena prvotně pro používání na zařízeních s vysokým rozlišením a větší úhlopříčkou displeje, grafický koncept počítal s tím, že bude používaná výhradně na tabletech. Jasným cílem je vytvořit aplikaci tak, aby byla přehledná a intuitivní. Zároveň od samého počátku při kreslení různých obrazovek vznikaly požadavky na programové oblasti.

Grafický návrh například ukázal, že nejsnadnější řešení je rozdělení celého programu na dvě záložky, kde první bude obsahovat správce souborů a projektů, druhá samotný prohlížeč grafů. Díky záměrné inspiraci běžným prohlížečem webových stránek vznikl také nápad umožnit uživateli mít otevřených více grafů zároveň a přepínat mezi nimi stejně jako při surfování. K tomuto řešení je využit jednoduchý panel otevřených projektů.

Obrázek 5 – obrazovka správce souborů

(16)

Při grafickém návrhu se počítalo s tím, že bude aplikace nasazena na tablety s OS Android 3.x a vyšším, proto bylo možné jednotlivé obrazovky rozdělit do fragmentů. Fragment je objekt, který může i nemusí obsahovat grafickou vrstvu, ale co je zásadní – jeho běh je řízen životním

cyklem, proto může reagovat na různé události (onCreate(), onDestroy(), atd.). Díky této analýze v grafické aplikaci bylo možné si zásadně rozvrhnout nejenom vzhled, ale i objektové uspořádání grafického prostředí. Zároveň to nakonec umožnilo i jednoduché přepracování programu pro telefony.

Spousta myšlenek, které se při navrhování zdály být jednoduché, se při programování ukázaly problematické, některé věci byly dodrženy do detailu a jiné bylo nutné modifikovat. V zásadě lze říci, že grafický návrh výrazně přispěl k ujasnění, jakou cestou se má výsledný program ubírat a jak má komunikovat s uživatelem.

Návrh programu je řešen tak, aby aplikace nebyla prvotně jednoúčelová. To je zásadní v celém pojetí této práce. Aplikace by měla umožnit uživateli velký prostor možností, jak data zobrazovat. Ohled byl také kladen na to, aby program mohl použít kdokoliv, kdo vlastní jakákoliv data ve formátu CSV, nejenom ten kdo používá PLC od společnosti Teco.

Obrázek 6 – obrazovka prohlížeče grafu

(17)

5.3. Odposlech HTTP komunikace

Jako nejvhodnější z komunikačních dovedností PLC řady Tecomat Foxtrot pro tuto práci je webový server, který je obsažen na každém z těchto PLC. Použití připojení k webovému serveru umožní stahovat již archivované soubory z SD karty. Zároveň toto řešení bude plně obecné a připravené k použití pro všechny, kteří toto PLC používají.

Nejdříve je však nutné prozkoumat, jak webový server funguje. V zásadě je nutné překonat jen jednu překážku, a tím je přihlašování. Pokud si uživatel zadá v prohlížeči IP adresu svého PLC zařízení, nejdříve je nasměrován na login obrazovku. Až po úspěšném zadání přihlašovacích údajů je přesměrován na samotné webové rozhraní, na kterém se zobrazuje přesně to, co si navrhnul ve vývojovém prostředí. Možností je mnoho, od obrázků, přes tlačítka, až po pole obsahující aktuální proměnné. To však závisí na uživateli, obecně tam nemusí být vůbec nic. Důležité je, že se tímto způsobem lze dostat k souborům na kartě SD.

Pro implementování přihlašování na PLC je nutné odposlechnout jak komunikace mezi klientem a serverem funguje. Vše je samozřejmě založeno na aplikačním protokolu http, což je nešifrovaný protokol, který je možné odposlechnout například programem Wireshark.

Obrázek 7 - WireShark

Http zpráva je složena z hlaviček a obsahu. Hlavičky slouží jako nezveřejňované informace, naopak obsah je zveřejňován prohlížečem webových stránek. HTTP protokol umožňuje dvě základní metody výměny informací GET a POST. Často se objevuje ve zprávě i tak zvaný

(18)

status kód, který poskytuje základní informace o tom, zda byl požadavek na web server úspěšně splněn či nikoliv.

Průběh komunikace:

První dotaz na web server může vypadat jako následující ukázka, je to dotaz vytvořený prohlížečem. Obsahuje spoustu nedůležitých informací, jako používané jádro prohlížeče, atd.

GET / HTTP/1.1 Host: 192.168.1.1 Connection: keep-alive

User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.91 Safari/534.30

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch

Accept-Language: cs-CZ,cs;q=0.8,en;q=0.6,en-US;q=0.4 Accept-Charset: windows-1250,utf-8;q=0.7,*;q=0.3

PLC odpovídá následujícím způsobem. Zajímavé je především použití hlavičky Set-Cookie.

PLC vyslalo speciální identifikační číslo 25838403. Další věc je také požadavek na přesměrování prohlížeče z výchozí stránky na /syswww/login.xml.

HTTP/1.1 302 Found Content-Type: text/html Content-Length: 0

Location: http://192.168.1.1/syswww/login.xml Set-Cookie: SoftPLC=25838403; Path=/

Cache-Control: no-cache

Druhý dotaz prohlížeče již uplatňuje přesměrování a zároveň zasílá zpět identifikační cookie.

GET /syswww/login.xml HTTP/1.1 Host: 192.168.1.1

Connection: keep-alive

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: cs-CZ,cs;q=0.8,en;q=0.6,en-US;q=0.4

Accept-Charset: windows-1250,utf-8;q=0.7,*;q=0.3 Cookie: SoftPLC=25838403

(19)

PLC po obdržení správné cookie odpovídá již s přihlašovací stránkou.

HTTP/1.1 200 OK Content-Type: text/xml Cache-Control: no-cache Content-Length: 195

Set-Cookie: SoftPLC=25838403; Path=/

<?xml version="1.0" encoding="windows-1250" ?>

<?xml-stylesheet type="text/xsl" href="login.xsl" version="1.0"?>

<LOGIN>

</LOGIN>

Po zadání přihlašovacího jména a hesla, prohlížeč vysílá nově metodou POST zadané údaje, společně s původní cookie.

POST /syswww/login.xml HTTP/1.1 Host: 192.168.1.1

Referer: http://192.168.1.1/syswww/login.xml Content-Length: 13

Cache-Control: max-age=0 Origin: http://192.168.1.1

Content-Type: application/x-www-form-urlencoded

Accept-Language: cs-CZ,cs;q=0.8,en;q=0.6,en-US;q=0.4 Accept-Charset: windows-1250,utf-8;q=0.7,*;q=0.3 Cookie: SoftPLC=25838403

USER=1&PASS=1

(20)

PLC reaguje jednoduchou zprávou s novou cookie a požadavkem na přesměrování.

HTTP/1.1 302 Found Content-Type: text/html Content-Length: 0

Location: http://192.168.1.1/PAGE2.XML Set-Cookie: SoftPLC=25841138; Path=/

Cache-Control: no-cache

Další dotaz je na přesměrovanou adresu s novou cookie už klasickou metodou GET.

GET /PAGE2.XML HTTP/1.1 Host: 192.168.1.1

Referer: http://192.168.1.1/syswww/login.xml Cache-Control: max-age=0

Accept-Language: cs-CZ,cs;q=0.8,en;q=0.6,en-US;q=0.4 Accept-Charset: windows-1250,utf-8;q=0.7,*;q=0.3 Cookie: SoftPLC=25841138

Po úspěšném přihlášení a dodržení změny cookie, PLC posílá nazpět v obsahu požadovanou webovou stránku s vizualizací.

HTTP/1.1 200 OK Content-Type: text/xml Cache-Control: no-cache Content-Length: 343

Set-Cookie: SoftPLC=25841138; Path=/

<?xml version="1.0" encoding="windows-1250" ?>

<?xml-stylesheet type="text/xsl" href="PAGE2.XSL" version="1.0" ?>

<PAGE>

</PAGE>

(21)

6. Implementace

6.1. Zajímavosti v Androidu

Activity

Třída Activity je základním stavebním kamenem každé aplikace. Její instance je nezávislý objekt, jenž je řízen životním cyklem. Aktivita může nebo nemusí obsahovat grafické rozhraní, většinou ale obsahuje. Protože je navrhnuta jako nezávislá, není možné ji předávat reference na jiné objekty, při startu může dostávat pouze referenci na objekty implementující rozhraní Serializable nebo přijímat elementární datové typy (Integer, String, atd.).

Obrázek 8 - životní cyklus aktivity, podle [5]

Protože je aktivita řízena životním cyklem, reaguje na možné události v rámci onoho cyklu.

V zásadě může nastat jen několik možností, při kterých by se měla aktivita různě chovat, a to je při různém způsobu ukončení. Nejjednodušší varianta je, když uživatel spustí jinou aktivitu, stará aktivita se zapauzuje, a následně se k ní uživatel vrátí tlačítkem zpět, tak nastane jen sekvence onPause() a onResume(). Pokud však dál pracuje s novou aktivitou a stará se tak stává neviditelnou a přechází do režimu onStop(). Pokud operační systém potřebuje více

(22)

paměti v některé ze spuštěných aplikací, získá ji obvykle ukončením nepotřebných aktivit.

Když uživatel však starou aktivitu spustí, je celá vytvořena znova s veškerými objekty.

Fragment

Fragment je jedna z nejdůležitějších tříd hned po Activity. Fragment byl představen až u Androidu verze 3 (tzn. Honeycomb). Vychází z filosofie, že to co se vejde na jednu obrazovku na tabletu, může být na telefonu rozloženo na dvě.

Obrázek 9 – fragmenty, podle [6]

Fragment musí být spuštěn v aktivitě. Fragment stejně jako aktivita má svůj vlastní životní cyklus. Pomocí takzvaného fragment manažeru je možné fragmenty libovolně přidávat či odebírat.

Fragment může i nemusí obsahovat grafické rozhraní. Je spouštěn v základním vlákně aplikace, a používá se především na rozdělení programu na části podle obsahu.

(23)

GUI v XML vs. v kódu

Android umožňuje psát GUI v XML i v kódu. Rozdíly jsou zřejmé. V XML se layouty deklarují velice jednoduše a rychle. Umožňují použití stylů. Problém nastává tehdy, když je třeba zobrazit více podobných nebo stejných prvků. Řešení pomocí cyklu není možné.

<SeekBar

android:layout_marginLeft="6dp"

android:max="100"

android:progress="50"

android:id="@+id/mdescAccValue"

android:layout_height="wrap_content"

android:layout_width="200dp"/>

Kód 1 – příklad deklarování grafického objektu v XML

Psaní grafiky v Javě je vhodné i tehdy, pokud je potřeba vytvořit vlastní komponenty. Stačí zdědit z třídy View a implementovat vhodné metody. Možností je přidat i vlastní grafickou komponentu do XML.

<android.joystick.device.views.ViewRobotRange android:id="@+id/viewRobotRange"

android:layout_width="fill_parent"

android:layout_height="fill_parent"

android:layout_weight="1"/>

Kód 2 – příklad použití vlastní grafické komponenty v XML

Někdy je rozumné tyty dva styly kombinovat. Každému prvku (př. String, Color nebo Button) je možné v XML přiřadit takzvaný identifikátor – globální proměnou, které je automaticky přidělena číselná hodnota. Tyto číselné hodnoty se generují do souboru R.java. Všechny prvky, kterým byl přidělen identifikátor, jsou viditelné i ze zdrojového kódu aplikace. Díky tomuto přístupu si můžu vytvořit základní layout v XML, pak si díky identifikátoru načíst vhodný kontejner pro grafické komponenty (př. LinearLayout) a přidat do něj dynamicky vlastní grafické objekty.

(24)

Strings.xml

Strings.xml se výborně hodí na vytváření různých jazykových mutací GUI. Všechny konstantní řetězce je možné zavést v tomto souboru s tím, že vhodný XML soubor se automaticky vybírá podle vybrané jazykové mutace sytému. Je tedy velice jednoduché podporovat různé jazykové verze programu.

Podpora různých obrazovek

Android je nasazen na mnoha zařízeních s odlišnými displeji. Pro to je vytvořena podpora a programátor může vytvářet layouty speciálně pro různé velikosti obrazovky. Taktéž obrázky je možné načítat podle density displeje. Zásadní zlom přinesl Android Honeycomb, který zavedl podporu výše zmíněných fragmentů, které lze načítat libovolně pro různé rozlišení či orientace displeje.

(25)

6.2. Obecné koncepce aplikace

Využití XML v projektech

Hlavním požadavkem zadání této práce je možnost zobrazovat data uložená v souborech typu CSV. Tento formát však není vhodný z programátorského hlediska, špatně se deserializuje.

Problém je v tom, že přechod mezi podkladovými daty v objekt, se kterým lze jednoduše pracovat by byl poměrně pomalý. Dalším nevhodným faktorem by byla nepřehlednost a především složitá rozšiřitelnost. Pokud by bylo nutné do souboru uložit nějaké další informace, narušovalo by to danou strukturu a složení dat v CSV souboru.

Obrázek 10 – obrazovka z aplikace

Z výše zmíněných důvodů byla zvolena cesta nepřímého zobrazení těchto dat a koncepce v podobě projektů, které je potřeba nejdříve vytvořit. Proto pro zobrazení dat je nejdříve nutná konverze do formátu projektu. Jako textový formát byl zvolen XML, který je přehledný a umožňuje snadnou serializaci. Veškerá data obsažená v podkladovém souboru se zkopírují do XML a zároveň se přidají další parametry jako jméno projektu a ostatní informace.

Jako další vhodné řešení se jeví i možnost ukládání projektů do databáze, tato cesta by zajistila mnohem rychlejší práci s daty. Argumentem proti tomuto řešení je však složitější úprava složení sloupců v tabulkách při již hotovém návrhu, a především nemožnost již hotové projekty jednoduše zkopírovat a případně použít na jiné platformě.

(26)

Koncepce layoutů a přizpůsobení se obrazovce

Aby se aplikace dokázala přizpůsobit všemožným zařízením, jsou deklarovány různé layouty, které definují vzhled některých obrazovek. Ty se mohou navzájem mírně lišit, jedná se především o adaptaci některých formulářových prvků.

Speciálně navrženo je umístění akčního panelu (tzv. ActionBar), který je na tabletech zobrazen vpravo nahoře. Tento panel tvoří obvykle kontextovou nabídku možností. Na telefonech se z důvodu nedostatku místa tento panel přesouvá dolů, kde je uživateli zároveň i více při ruce. V případě, že je panel dole, je jeho obsah omezen čtyřmi ikonkami, pokud je nutné více možností, je zbytek zobrazen po stisknutí tlačítka menu.

Kvůli nedostatku místa na displeji telefonů aplikace zároveň ztrácí panel otevřených projektů.

Možnost přepínání projektů je implementována jedním tlačítkem, pod kterým se skrývá plovoucí menu, které zobrazí otevřené grafy.

Obrázek 11 - aplikace spuštěná na zařízení s rozlišením 1280x800 a 480x800

(27)

Dialogy a funkce na pozadí

Práce s daty je často náročná na výkon procesoru. Větší soubory se zpracovávají dlouho.

Aplikace se však nesmí zaseknout, je proto nutné vytvořit vyčkávací dialog. Pro tento účel slouží dva druhy možných dialogů. První zobrazuje stav operace v procentech, druhý ukazuje pouze vyčkávací animaci.

Většina použitých dialogů obsahuje tlačítko Zrušit, které ukončí aktuálně prováděnou operaci.

Zajímavá je však funkce Na pozadí, jež umožní uživateli zavřít dialogové okno, avšak neukončit aktuální operaci. Uživatel může libovolně pracovat s aplikací, když se však daná operace dokončí, uživatel je o tom informován a může na to navázat.

6.3. Programová koncepce aplikace

Aplikace se částečně drží své předlohy z grafického návrhu. Používá několik novinek představených v API pro Honeycomb. Využívá grafické téma Holo, které upravuje styl zobrazení jednotlivých standardních grafických komponent.

Celý program využívá v zásadě jen jednu aktivitu, která se jmenuje ActivityMain, tato aktivita si drží statické fragment manažery, které byly naprogramovány speciálně pro případ této aplikace, výchozí fragment manažery totiž nevyhovovaly svými funkcemi. Tyto objekty se starají o přechod mezi obrazovkami. Aktivita zároveň vytváří ActionBar, který musí být pro každou aktivitu jedinečný. Také z důvodu rozsáhlého využití ActionBaru byl zvolen koncept využití jen jediné aktivity společně s mnoha měnícími se fragmenty.

Obrázek 12 – dialog zobrazující pouze animaci Obrázek 13 – dialog zobrazující stav operace

(28)

Obrázek 14 – ActionBar – akční panel

ActionBar obsahuje často jméno a ikonku aplikace, některá stálá tlačítka a především dynamická tlačítka, která se mění podle aktuálního použitého fragmentu. Tato část zobrazuje uživateli přehlednou kontextovou nabídku.

Některé z fragmentů jsou deklarovány pomocí XML, převážně ty, jejichž obsah se nemění.

Většina fragmentů však jsou naprogramována v klasickém kódu. Snahou je, aby splňovaly koncepci Model – View – Controller. To znamená, že fragment jako takový se obvykle stará o funkčnost jednotlivých grafických komponent, a svazuje je dohromady s daty. Grafické komponenty plní pouze zobrazovací funkci, všechny události jsou implementovány na vrstvě fragmentu. Fragment zároveň plní grafické komponenty daty. Data jsou deklarována ve speciálních třídách, naplněna jsou za pomocí zvláštních objektů, jež se starají jen o práci s nimi. Tento přístup má zajistit přehledný a krátký kód, kde každá třída má za úkol poměrně malý rozsah funkcí.

Obrázek 15 – MVC [7]

(29)

6.4. Struktura zdrojového kódu

Následující seznam ukazuje seznam použitých balíčků (package) v aplikaci. Celé řešení obsahuje 17 balíčků, 162 tříd, 33 rozhraní a 8195 řádků kódu. Statistiky nezahrnují layouty deklarované v XML.

com.android.graph.activities – aktivity, které jsou použity v aplikaci

com.android.graph.activities.graph – fragmenty a rozhraní, které jsou využity v prohlížeči projektů

com.android.graph.activities.project – fragmenty, které jsou využity pro tvorbu projektů com.android.graph.activities.storage – fragmenty, které jsou použity pro správce souborů com.android.graph.adapters – adaptéry nutné pro použité ListView

com.android.graph.controllers – různé třídy plnící funkční vrstvu v programu com.android.graph.controllers.dialogs – funkční vrstva dialogů

com.android.graph.data – pomocné třídy určené k práci s daty

com.android.graph.filemanager – třídy zajišťující funkci správce souborů com.android.graph.global – globální proměnné a konvertor datových typů com.android.graph.plot – třídy zajišťující vykreslování grafu

com.android.graph.project – datové struktury určující projekt – vrstva model pro aplikace com.android.graph.views – třídy dědící z třídy View nebo z jeho dětí

com.android.teco.espnet – návrh implementace protokolu Epsnet com.android.teco.epsnet.dataclass – datové typy použité v Epsnetu com.android.teco.epsnet.messagedata – příkazy použité v Epsnetu

com.android.teco.http – komunikační třídy zajišťující připojení k web serveru

(30)

6.5. Ukázky ze zdrojového kódu

6.5.1. TecoConnector

TecoConnector je třída, která se stará o HTTP komunikaci se zařízením Tecomat Foxtrot.

Tato třída obsahuje především privátní metodu makeConnection(), která je volána z veřejné metody connect(). Metoda makeConnection() má na starost připojení k PLC pomocí po sobě jdoucích dotazů na web server. Tyto dotazy jsou prováděny pomocí objektu třídy HttpClientHandler. Metoda makeConnection() se provádí vždy v novém vlákně, pokud do 12 sekund nedojde k úspěšnému navázání připojení, je vytvořen další pokus a starý ukončen.

Pokus o připojení je proveden maximálně třikrát.

Třída HttpClientHandler využívá dva objekty, jež jsou schovány za jeden pomocí abstrakce.

Tyto dva objekty mají na starost odesílání a přijímání HTTP zpráv; jeden objekt využívá GET a druhý SET. Mezi těmito objekty může HttpClientHandler libovolně přepínat. Obsahuje metody jako setCookie(), setHeader(), setHost(), getLocation(), getEntityContent().

Třída TecoConnector obsahuje následující veřejné metody:

 setITecoProgress() – metoda pro nastavení posluchače, posluchač zveřejňuje postup stáhnutí souboru

 isAvailable() – metoda ověřuje dostupnost hostitelského PLC

 connect() – metoda se připojuje k PLC po zadání přihlašovacích parametrů

 fileExists() – metoda ověřuje existenci souboru, jméno souboru se zadává jako parametr

 fileDownload() – metoda dokáže stáhnout soubor z hostitelského PLC

(31)

6.5.2. FileManager

FileManager je jednoduchou implementací prohlížeče souboru. Objekt si pamatuje aktuální úroveň, dokáže vrátit seznam souborů a složek, přecházet mezi úrovněmi, mazat a přejmenovávat položky v souborovém systému. Tato třída zajišťuje pouze funkční vrstvu, grafická vrstva může být jakákoliv. Tento způsob je ukázkou využití konceptu View- Controller.

public class FileManager { private File currentFile;

public FileManager(File currentFile){

this.currentFile = currentFile;

}

public boolean createDirectory(String name){

if(currentFile.canWrite()){

File newF = new File(currentFile.getPath() + "/" + name);

newF.mkdir();

if(newF.exists()) return true;

}

return false;

}

public boolean createFile(String name){

if(currentFile.canWrite()){

try {

newF.createNewFile();

if(newF.exists()) return true;

} catch (IOException e) { e.printStackTrace();

} }

return false;

}

public boolean deleteItem(String name){

if (currentFile.canWrite()) {

if (newF.exists()) {

if(newF.isDirectory()){

deleteFolder(newF);

return true;

}

else return newF.delete();

} }

return false;

}

private void deleteFolder(File fileOrDirectory){

if (fileOrDirectory.isDirectory())

for (File child : fileOrDirectory.listFiles())

(32)

deleteFolder(child);

fileOrDirectory.delete();

}

public boolean rename(String oldName, String newName){

if (currentFile.canWrite()) {

File oldF = new File(currentFile.getPath() + "/" + oldName);

if (oldF.exists()) {

File newF = new File(currentFile.getPath() + "/" + newName);

oldF.renameTo(newF);

if(!oldF.exists() && newF.exists()) return true;

} }

return false;

}

public boolean changeCurrentLevel(String rPath){

File dirLevel;

if(rPath.equals("..")){

dirLevel = new File(currentFile.getParent());

}else{

dirLevel = new File(currentFile.getPath() + "/" + rPath);

}

if(dirLevel.isDirectory() && dirLevel.list() != null){

currentFile = dirLevel;

return true;

}

else return false;

}

private File[] sort(File[] list){

Arrays.sort(list, new Comparator<File>() {

@Override

public int compare(File object1, File object2) {

if((object1.isDirectory() && object2.isDirectory()) ||

(object1.isFile() && object2.isFile())){

String ob1 = object1.getName().toLowerCase();

String ob2 = object2.getName().toLowerCase();

return ob1.compareTo(ob2);

}

else if(object1.isDirectory() && object2.isFile()){

return -1;

} else{

return 1;

} }

});

return list;

}

public FileItem[] getCurrentFileList() { ...

} }

Kód 3 – třída FileManager

(33)

6.5.3. DialogAsyncWaiting

Třída DialogAsyncWaiting rozšiřuje třídu AsyncTask, což je velice přínosná třída umožňující jednoduché vytváření nových vláken. V zásadě AsyncTask obsahuje několik vhodných metod k přepsání:

onPreExecute() – tato metoda nastane v hlavním vlákně ještě před vytvořením nového doInBackground() – tato metoda je volána v novém vláknu a měla by obsahovat časově náročnější operace

onPostExecute() – metoda je zavolána z vlákna GUI po skončení operací v novém vlákně

onProgressUpdate() – tato metoda se vykonává ve vlákně GUI a může být zavolána pomocí publishProgress() odkudkoliv

Objekt třídy DialogAsyncWaiting má jediný účel, a to vykonat potřebné operace v pozadí zatímco uživatel uvidí vyčkávací dialog. Grafický dialog je vyvolán až po uplynutí 500ms.

Tato hodnota byla zvolena jako maximální, kdy uživatel ještě nepozná pomalou odezvu grafického rozhraní. Uživateli může nebo nemusí být umožněno dialog zavřít a pokračovat s prací v aplikaci, zatímco se vykonávají potřebné věci v pozadí.

public class DialogAsyncWaiting extends AsyncTask<Void, Integer, Void> implements IDialogAsync{

private Context ctx;

private Timer myTimer;

private ProgressDialog dialog;

private ITaskProvider taskProvider;

private boolean autoDialogCancel = true;

private boolean onBackground = false;

public DialogAsyncWaiting(Context ctx) { this.ctx = ctx;

dialog = new ProgressDialog(ctx);

dialog.setCancelable(true);

dialog.setButton(ctx.getString(R.string.cancel), new DialogInterface.OnClickListener() {

@Override

public void onClick(DialogInterface dialog, int id) { if (cancel(true))

myTimer.cancel();

dialog.cancel();

cancel();

} });

}

(34)

this.cancel(true);

}

public void setTaskProvider(ITaskProvider taskProvider){

this.taskProvider = taskProvider;

}

public void allowOnBackroundButton(){

...

}

@Override

protected void onPreExecute() { myTimer = new Timer();

myTimer.schedule(new TimerTask() { int time = 0;

@Override

public void run() { time += 100;

if (time > 500) {

publishProgress(time);

this.cancel();

} }

}, 0, 100);

} ...

@Override

protected void onProgressUpdate(Integer... values) { dialog.show();

super.onProgressUpdate(values);

}

@Override

protected void onPostExecute(Void result) { if (dialog != null && autoDialogCancel){

dialog.cancel();

myTimer.cancel();

} else

myTimer.cancel();

if(taskProvider != null)

taskProvider.doAfterFinish();

super.onPostExecute(result);

}

@Override

protected Void doInBackground(Void... params) { if(taskProvider != null)

taskProvider.doInBackground();

return null;

} }

Kód 4 – třída DialogAsyncWaiting

(35)

7. Závěr

V rámci bakalářské práce se úspěšně podařilo navrhnout a vytvořit funkční aplikaci. Aplikace dokáže zpracovávat veškeré druhy CSV souborů, komunikovat s PLC Tecomat Foxtrot pomocí web serveru a zobrazovat veškerá data v grafech. Program funguje na mobilních telefonech a tabletech založených na operačním systému Android. Součástí práce je podrobný uživatelský manuál pro práci s programem, CD s přiloženými zdrojovými kódy a instalačním souborem.

(36)

Seznam použité literatury

[1] Monitoring experimentů ve štole Josef. TECO A.S.Tecomat[online]. [cit. 2012-05-12].

Dostupné z: http://www.tecomat.com/clanek-1389-reference---monitoring-experimentu-ve- stole-josef-.html

[2] Apache image directory. In:Ask Dave Taylor[online]. [cit. 2012-05-12]. Dostupné z:

http://www.askdavetaylor.com/create_apache_image_browser_script.html

[3] TECO A.S.Komunikační server PLCCOmS:uživatelská příručka[online]. 7. vyd. 2011 [cit. 2012-05-12]. Dostupné z:

http://www.tecomat.com/wpimages/other/DOCS/cze/TXV13863_01_PLCComS_cz.pdf

[4] Platform Versions. GOOGLE.Android Developers[online]. 1.5.2012. [cit. 2012-05-12].

Dostupné z: http://developer.android.com/resources/dashboard/platform-versions.html

[5] Activity: Activity Lifecycle. GOOGLE.Android Developers:Reference[online].

[cit. 2012-05-12]. Dostupné z:

http://developer.android.com/reference/android/app/Activity.html

[6] Fragments: Design Philosophy. GOOGLE.Android Developers:Reference[online].

[cit. 2012-05-12]. Dostupné z:

http://developer.android.com/guide/topics/fundamentals/fragments.html

[7] Model–view–controller. In:Wikipedia:the free encyclopedia[online]. San Francisco (CA):

Wikimedia Foundation, 2001- [cit. 2012-05-12]. Dostupné z:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

[8] Telnet. In:Wikipedia:the free encyclopedia[online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2012-05-12]. Dostupné z: http://cs.wikipedia.org/wiki/Telnet

[9] TECO A.S. Sériová komunikace programovatelných automatů Tecomat [online]. 17. vyd.

2010 [cit. 2012-05-14]. Dostupné z:

http://www.tecomat.com/wpimages/other/DOCS/cze/TXV00403_01_Comm_Serial32_cz.pdf

(37)

Seznam použitých obrázků

Obrázek 1 – areál štoly Josef [1] ... 7

Obrázek 2 – ukázka webového rozhraní používaného pro experimenty v Josefu ... 9

Obrázek 3 – ukázka možného výpisu souborů na web serverech Apache [2] ... 10

Obrázek 4 – komunikační schéma pro PLCComS [3] ... 11

Obrázek 5 – obrazovka správce souborů ... 15

Obrázek 6 – obrazovka prohlížeče grafu ... 16

Obrázek 7 - WireShark ... 17

Obrázek 8 - životní cyklus aktivity, podle [5] ... 21

Obrázek 9 – fragmenty, podle [6] ... 22

Obrázek 10 – obrazovka z aplikace ... 25

Obrázek 11 - aplikace spuštěná na zařízení s rozlišením 1280x800 a 480x800 ... 26

Obrázek 12 – dialog zobrazující pouze animaci ... 27

Obrázek 13 – dialog zobrazující stav operace ... 27

Obrázek 14 – ActionBar – akční panel ... 28

Obrázek 15 – MVC [7] ... 28

(38)

Seznam zkratek

API – Application Programming interface – programovací rozhranní

CSV – Comma Separated Values – hodnoty oddělené čárkou

GUI – Graphic User Interface – grafické rozhraní

HTTP – Hypertext Transfer Protocol – protokol určený na výměnu textových dokumentů

IDE – Integrated Development Enviroment – vývojové prostředí

IP – Internet Protocol – protokol zajišťující adresující vrstvu

OS – Operating System – operační systém

PLC – Programmable Logic Controller – řídicí programovatelné zařízení

SDK – Software Development Kit – nástroje pro programování

SQL – Structured Query Language – dotazovací jazyk

TCP – Transmission Control Protocol – protokol zajišťující spolehlivou transportní vrstvu

XML – Extensible Markup Language – rozšířený značkovací jazyk

(39)