Ovládání systému inels a imm v OS Android

Transkript

1 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická Katedra měření Ovládání systému inels a imm v OS Android DIPLOMOVÁ PRÁCE Vypracoval: Bc. Vlastimil Venclík Vedoucí práce: doc. Ing. Jiří Novák, Ph.D. 2012

2 PROHLÁŠENÍ Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady (literaturu, projekty, SW atd.) uvedené v přiloženém seznamu. V Praze dne: podpis

3

4 Anotace Cílem práce je seznámení s návrhem aplikace pro ovládání domu v systémech inels a imm od společnosti Elko EP s.r.o. Oba systémy jsou popsány v první části práce. Jako cílový operační systém byl vybrán systém Android, jehož nejdůležitější části jsou v práci popsány. Aplikace byla vytvořena jak pro mobilní telefony, tak pro zařízení typu tablet. Společná logická a komunikační část obou aplikací je popsána v samostatné kapitole. V poslední části práce jsou popsána specifika obou variant programu a vhodná referenční zařízení. Podrobně jsou rozebrány rozdíly v grafické implementaci. V závěru práce jsou uvedena možná další zlepšení a návrhy na další rozvoj. Annotation The thesis of this work aims to introduce the design of the application which is implementing control of inels and imm systems developed by Elko EP s.r.o. company. Both systems are described in the first part of this work. As the target operating system has been chosen Android mobile system of which the most important parts are described in a separate chapter. Application was created for mobile phones and devices called tablet. Common logical and communication part of both applications is described in a separate chapter. Proper reference devices and both application differences are in the last part of the work. Differences of graphical implementations are analyzed there in detail. Possible next improvements and suggestions are presented in the end of this work.

5 PODĚKOVÁNÍ Děkuji vedoucímu mé práce doc. Ing. Jiřímu Novákovi, Ph.D. za jeho ochotu a cenné rady. Dále firmě Elko Ep s.r.o. za možnost pracovat na tomto tématu a za materiální zajištění projektu. Velký dík patří mé rodině, která mi umožnila studovat a dopřála mi tak dost prostoru vypracovat tuto práci.

6 Obsah KAPITOLA Úvod Shrnutí cílů práce Současné typy domovních instalací Systém inels Centrální jednotka CU2-01M Komunikace v systému inels Protokol EPSNET Komunikační prostředky protokolu EPSNET Instalační soubor Multimediální systém imm Konfigurační rozhraní systému imm Ovládání spotřebičů MIELE Celkové zapojení systému KAPITOLA

7 2. Operační systém Android Verze operačního systému a napojený ekosystém Architektura systému Struktura aplikací Charakteristika komponenty Activity Charakteristika komponenty Service Charakteristika komponenty Broadcast Receiver Charakteristika komponenty Content Provider Vlastnosti objektu Intent Soubor AndroidManifest.xml Zdroje dat aplikace Grafický systém Grafická komponenta ListView Menu systém Vstupní uživatelské události Úložiště dat Vlákna a asynchronní operace KAPITOLA Společné vlastnosti aplikace pro mobily a tablety Komunikační služba Komunikace se systémem inels Komunikace se systémem imm Zahájení komunikace a stažení dat ze serveru Uložení dat a přidružené datové struktury Licencování KAPITOLA

8 4.1 Aplikace pro tablety a referenční zařízení Grafická implementace hlavní obrazovky Ikona meteostanice Popis fragmentů Klimatizace Ovládání multimédií Prohlížení fotografií Spotřebiče Miele Bezpečnostní kamery MJPEG Zobrazení dat z kamery Nahrávání obrazu z kamery KAPITOLA Aplikace pro mobilní telefony Grafická implementace hlavní obrazovky Animace komponent Ovládání prvků Ovládání spotřebičů s pomocí náklonu zařízení Další rozvoj Závěr Seznam literatury Seznam obrázků Seznam tabulek Seznam zkratek Obsah CD... 69

9 KAPITOLA Úvod Technologický pokrok za posledních několik desetiletí umožnil prudký rozvoj a rozmach nových technologií definujících novou kategorii budov, a to inteligentní budovy. Takovéto budovy nabízejí na svou dobu nebývalý komfort bydlení a užívání zaručený použitím nejmodernějších způsobů konstrukce a použití vnitřních systémů řízení budovy. Tyto systémy můžeme rozdělit na technologie pro měření stavu vnitřního prostředí, technologie pro jeho regulaci, různé systémy pro úsporu energií či použití například modernějších materiálů při stavbě. Mezi technologie pro kontrolu vnitřního prostředí můžeme zařadit různé systémy pro zjištění stavu teploty v budově, vlhkosti vzduchu či obsah různých plynů v budově. Poté nastupují systémy řízení, které na změřené veličiny reagují a nastavují akční členy do požadovaných hodnot. Dnes velmi často používaným způsobem kontroly teploty v budově je například regulace dle ekvitermní křivky. Za poměrně samozřejmou se pokládá i instalace různých zabezpečovacích prvků ať už různých magnetických senzorů, či kamerových systémů. Škála takto koncipovaných budov je velice různorodá, počínaje rodinnými domy, přes různé funkční haly a konče kancelářskými či výškovými budovami. Pojem inteligentní budova proto v sobě zahrnuje propojení různých systémů a stupňů kontroly budovy, které umožňují řízení vnitřního prostředí budovy a její regulaci. Nicméně nejedná se jen a pouze o systémy kontroly. Už při návrhu budovy je nutno postupovat dle úsporných ekologických standardů, snížit energetickou náročnost budovy a počítat s místem pro instalaci řídicích systémů. Další výzvou pro projektanty takovýchto komplexních řešení je prezentace a vizualizace naměřených dat uživateli. Zde se musí také rozlišovat typ stavby. Je nesporné, že pro rodinné domy by grafická reprezentace daného systému musela být více uživatelsky přívětivá než například pro průmyslovou stavbu, kde se klade důraz jen a pouze na funkčnost Shrnutí cílů práce Rozvoj mobilní techniky v několika posledních letech dovolil nebývalé možnosti propojení takovýchto staveb s různými mobilními telefony či novou kategorií zařízení zvaných tablety. Obrovskou výhodou je jich mobilita a snadnost používání, neboť například mobilní telefon má dnes člověk stále při sobě. Je proto jistě uživatelsky pohodlné mít možnost pomocí tabletu ovládat budovu či přehrávat multimédia. Proto se započalo s vývojem aplikace vhodné pro takovéto zařízení. Cílem práce by tedy mělo být vytvoření aplikace schopné graficky přitažlivou formou nabídnout uživateli vizualizaci naměřených dat a jejich změnu. Hlavním cílovým 9

10 zařízením by měl být tablet, ale logická část aplikace by měla být přenositelná i na mobilní telefon. Obě zařízení by měli být vybaveny operačním systémem Android. Pro systém inels již existuje externí aplikace schopná ho ovládat. Je vyvíjena ruskou společností iridium Mobile a jmenuje se iridium for inels [1]. Nicméně tato aplikace je určena jen pro operační systém ios a Windows. Navíc neumí komunikovat se systémem imm a tudíž není plně kompatibilní se všemi produkty. Systém inels už nelze jinak ovládat bez použití řešení imm. V současné době existuje více mobilních aplikací určených pro ovládání domu a většina z nich je založena na vlastním řešení elektroinstalace. Tyto systémy vesměs postrádají ovládání multimédií stejně tak jako další pokročilé funkce pro práce s nimi. Například neumějí zobrazovat či nahrávat obraz z bezpečnostních kamer [2]. 1.2 Současné typy domovních instalací V současnosti ve světě existuje mnoho různých typů řešení pro ovládání a řízení domů. Dá se říci, že každá větší firma zabývající se vývojem či výrobou řídicí a měřící techniky přišla se svým vlastním systémem. Tato řešení se často liší plánovaným použitím, např. rodinné domy či kancelářské prostory, mírou modulárnosti, tj. zda a kolik se dá k tomuto systému připojit dalších dílčích subsystémů, a poté hlavně cenou. Moderní systémy už také nenabízejí jen ovládání domácnosti, ale i kontrolu nad různými multimediálními centry, televizemi či hudebními přehrávači. Jak již bylo zmíněno dříve, je zde kladen důraz i na zabezpečení domu, například pomocí propojení na kamerový okruh či dodatečnou instalací a propojení protipožární techniky. Základem každého systému pro kontrolu domu je sběrnice, nad níž je vybudován. Pod pojmem sběrnice si lze představit skupinu vodičů, které se dělí na řídící, adresové a datové. K této sběrnici se připojují jednotlivé měřící, spínací a regulační prvky, které tvoří pomyslnou páteř každého systému. Některé sběrnice mohou mít spojeny různé typy skupin vodičů do jednoho, jenž pak zastává více funkcí. Můžeme provést základní rozdělení sběrnic na dva typy. Meteo senzor Řídící jednotka vytápění Senzor teploty Reléový výstup Obrázek 1 - Centralizovaná systémy 10

11 Prvním jsou centralizované systémy, které jsou charakteristické nutností komplexní kabeláže a zpracováním všech naměřených dat na jednom místě. Výhodou tohoto řešení je okamžitá dostupnost dat ze senzorů. Druhým typem jsou pak distribuované systémy, ty naopak podstatně snižují požadavky na kabeláž, a zvyšují tak flexibilitu celého systému. Řídící jednotka vytápění Meteo senzor Senzor teploty Reléový výstup Obrázek 2 Distribuované systémy Jednotlivé domovní systémy se mohou lišit i použitým komunikačním protokolem nad danou sběrnicí. Komunikačním protokolem je myšlen soubor pravidel a definic informující o průběhu komunikace po sběrnici, například tvoření a odesílání zpráv či jejich příjem. Protokol také musí definovat postup, jakým bude určeno, kdo bude v danou chvíli vysílat, aby se předcházelo chybám v komunikaci. 1.3 Systém inels Systém inels byl vyvinut firmou Elko EP s.r.o. ve spolupráci s firmou Teco a.s. Jedná se o plnohodnotnou platformu pro kontrolu a řízení domácnosti, která využívá centralizovanou strukturu. Mozkem celého systému je centrální jednotka založená na bázi PLC, která obstarává veškerou kontrolu nad připojenými prvky. K jednotce je možné připojit prvky pomocí sběrnice CIB (Common installation bus). Pro zapojení se používá pouze dvou vodičů, čímž je podstatně usnadněna domovní instalace. Pracovní napětí pro funkčnost sběrnice je definováno 24V. Napájecí napětí senzorů i aktorů je spolu s daty vedeno společně po dvou vodičích. Na jednu komunikační větev lze připojit až 32 zařízení, přičemž délka takovéto větve nesmí přesáhnout 300 metrů pro metalické vedení a 1700 metrů pro optické. Nicméně díky typu komunikace master-slave lze každou větev rozšířit o další jednotku master a tím zvětšit dosah instalovaného systému. Rychlost přenosu dat je definována na 19,2 kb/s spolu s odezvou maximálně 150 ms. Tato hodnota je velice důležitá, neboť subjektivně definuje rychlost systému a při příliš velké odezvě by sytém vypadal zpomaleně a neaktuálně. Každé zařízení připojené na tuto sběrnici má 11

12 svoji 16 bitovou adresu nastavenou napevno na čipu. Pro přehlednost je realizována pomocí čtyř hexadecimálních čísel. Pomocí této adresy pak centrální jednotka komunikuje se zařízením Centrální jednotka CU2-01M Implementaci sběrnice CIB v systému inels zajišťuje centrální jednotka s označením CU2-01M. Jak již bylo zmíněno, je založena na technologii PLC a pomocí speciálního software umožňuje konfiguraci přímo z uživatelského nebo servisního počítače. K jednotce lze připojit až dvě sběrnice CIB, čímž je schopna obsloužit až 64 zařízení. Další zařízení lze připojit pomocí externích modulů a rozšířit tak maximální počet až na 196 zařízení. Jednotka je také schopna monitorovat stav a úroveň náhradního napájení a v případě potřeby dobíjet záložní akumulátory. K indikaci stavu na jednotce slouží informační sedmisegmentový displej a stavové LED diody. Obrázek 3- Centrální jednotka CU2-01M [4] Pro snadnější kontrolu je na jednotku nainstalován webový server, který umožňuje vzdálené ovládání. Velkou výhodou jednotky je její vybavenost ethernet portem, přes který komunikuje s ostatními prvky systému imm a přes který také komunikuje s mobilními zařízeními. Centrála přijímá zprávy na portu PLC je schopno komunikovat ve čtyřech režimech PC, PLC, UNI, MDB. Režim PC je trvale aktivní, nabízí komunikaci se čtyřmi až šesti účastníky. Zároveň tento režim umožňuje programování PLC. Uživatel může volitelně aktivovat režim PLC, který dovoluje výměnu informací mezi jednotlivými PLC. Další dva režimy jsou popsány v následující kapitole Komunikace v systému inels Tato kapitola je částečně převzata z dokumentu Projekt 1 [3] [1], který předcházel této práci. Pro hlubší pochopení funkcí systému inels jsou však nezbytné. Systém inels využívá pro komunikaci přes ethernetovou přípojku svůj speciální síťový protokol. Je jím modifikovaná verze UDP komunikace, a to řešení známé pod název ESPNET. V rámci tohoto protokolu se 12

13 zasílají speciální ESPNET UDP pakety. Obecně pro snížení odezvy komunikace a komunikační režie je vhodné použít v takovýchto systémech UDP komunikaci, která neřeší, zda zpráva byla doručena na rozdíl od TCP/IP modelu. Režimy komunikace centrály UNI a MDB již nepoužívají speciální řešení EPSNET UDP, ale buď standardní UDP paket (UNI režim) nebo speciální MODBUS UDP paket (MDB režim). Pro komunikaci v UNI režimu je dovolena současná komunikace až osmi účastníků. Stejně jako PC režim i MDB režim je trvale aktivní a umožňuje současnou komunikaci mezi dvěma účastníky. Síť EPSNET jako taková umožňuje dva režimy komunikace, a to monomaster a multimaster. Jak názvy napovídají, v režimu monomaster funguje pouze jedna nadřízená centrální stanice. Režim multimaster se používá v situacích, kdy je v síti více nadřízených jednotek. Pro ovládání a kontrolu spotřebičů se v systému inels využívá režim multimaster. Struktura každého EPSNET UDP paketu pak může být poměrně rozdílná, neboť každý takovýto paket může obsahovat až 5 EPSNET zpráv. Tato vlastnost umožňuje efektivnější využití přenosového pásma a tím snižuje nároky na síťovou režii. Nicméně každý paket má předepsanou hlavičku o délce 6 bajtů, po kterém následují vlastní zprávy. Řídící PLC je poté schopno zpracovat tyto zprávy v pořadí, v jakém jdou za sebou v paketu. Příchozí odpověď je potom ve stejném tvaru jako dotaz x MESI PN R DPLEN EPSNET 1-5 Obrázek 4 Struktura paketu EPSNET UDP Význam jednotlivých zkratek je následující: Název Pozice bajtu Význam MESI 0-1 PN 2 R 3 Rezervní místo. DPLEN 4-5 Umožňuje jednoznačně identifikovat zprávu, je to unikátní identifikátor. Kód pro režim komunikace PLC (EPSNET Slave nebo ESPNET multimaster). Určuje délku následujících dat. Dle konvence obsahuje bajt 4 vyšší část délky a bajt 5 nižší. EPSNET a dále Samostatné zprávy sestavené dle EPSNET protokolu. Tabulka 1 - Popis polí v ESPNET UDP paketu 13

14 1.3.3 Protokol EPSNET Jak již bylo zmíněno, každý EPSNET UDP paket obsahuje až 5 EPSNET zpráv. Každá zpráva má poměrně variabilní délku, a proto není ani pevně stanovena délka paketu. Data jsou zde zabezpečena jednak dle kontroly přesně stanovenou sekvencí hodnot rámce protokolu 1 start bit, 8 datových bitů a 1 stop bit, dále pomocí kontrolního součtu v poli FCS a sudé parity. Pokud nejsou splněny tyto podmínky, dojde k zahození zprávy. Pro bezproblémovou komunikaci je dále stanovena podmínka klidu na lince v délce trojnásobku doby potřebné pro odeslání jednoho bytu. Obecná struktura zpráv protokolu je potom následující: a) Režim nadřízená stanice podřízené SD1 DA SA FC FCS ED Obrázek 5 - Zpráva bez datového pole SD2 LE LER SD2R DA SA FC DATA FCS ED Obrázek 6 - Zpráva s datovým polem SD4 DA SA Obrázek 7 - Zpráva token b) Režim podřízená stanice nadřízená Krátkým pozitivním potvrzením příkazu je datové pole SAC. Jiným typem potvrzení může být zpráva datově shodná s viz Obrázek 7. Pokud přijde odpověď s daty, je shodná jako paket naznačený viz Obrázek 6. 14

15 Použité zkratky mají následující význam: Zkratka Význam SD1 Úvodní znak 1 SD2 Úvodní znak 2 SD4 Úvodní znak 4 LE Délka dat LER Opakovaná délka dat SD2R Opakovaný úvodní znak 2 DA Cílová adresa SA Zdrojová adresa FC Řídící bajt rámce DATA Vlastní data zprávy FCS Kontrolní součet zprávy ED Koncový znak SAC Krátké potvrzení Tabulka 2 - Význam použitých zkratek Komunikační prostředky protokolu EPSNET Pro komunikaci s PLC slouží řada předem definovaných příkazů. Nejdůležitějšími jsou funkce pro započetí komunikace, identifikaci spojení, vyčítání stavů z datové paměti a zapisování do datové paměti. Přehled funkcí je následující: a) connect Před začátkem komunikace je potřeba inicializovat vnitřní struktury PLC. K tomu slouží tento příkaz. Tvar zprávy je shodný jako Obrázek 5, liší se pouze v hodnotě FC, která může být 49 nebo 69 v hexadecimálním tvaru. Ukázka volání funkce pro stanici s nastavenou adresou 0, které přiřadíme jinou, např. 80: zpráva - $10 $00 $50 $69 $E7 $16 odpověď - $10 $50 $00 $00 $7E $16 b) ident Tato funkce slouží k identifikaci připojeného systému. Pomocí ní se dá zjistit např. verze softwaru, verze implementovaného protokolu a další věci. Datový tvar zprávy je opět shodný jako Obrázek 5 a liší se konstantou FC, která může být 4E nebo 6E v hexadecimálním tvaru. Příchozí pozitivní odpověď má potom shodný tvar jako Obrázek 6, neboť obsahuje datové pole s popisem typu připojeného systému. 15

16 Datové pole vypadá takto: Bajt Označení Význam 0 LIS Délka identifikačního řetězce 1 LIP Délka typu implementace protokolu 2 LST Délka řetězce určujícího verzi struktur 3 LSW Délka řetězce určujícího verzi softwaru 4 - Identifikační řetězec centrální jednotky 4+LIS - Znak implementace protokolu 4+LIS+LIP - Řetězec verze struktur 4+LIS+LIP+LST - Řetězec verze softwaru Tabulka 3 - Popis datového pole funkce ident c) readn pro čtení z datové paměti Pro zjištění stavů jednotlivých zařízení slouží tato funkce, která také umožňuje vyčítat stavy z více registrů najednou. Struktura je následující: SD2 LE LER SD2R DA SA FC R DATA FCS ED Obrázek 8 - Struktura zprávy příkazu Real Význam konstant je stejný jako v tabulce 5, liší se jen tvarem. Pole LE a LER se určí dle vztahu: Kde n je počet čtených bloků dat. Do pole DATA se vkládá informace o registru, poté informace o adrese registru, ta je rozdělena do dvou bajtů, a nakonec počet čtených registrů. Takovýchto registrů je možné najednou vyčíst 62 v jedné zprávě. Celkem je možno vložit do jednoho EPSNET UDP paketu 5 zpráv, tj. 310 registrů. d) writen pro čtení z datové paměti Principielně je tvar této funkce stejný jako funkce readn, liší se pouze v datové části, kde se vkládají ještě zapisovaná data za adresy přístrojů. Správné přijetí zprávy je signalizováno odesláním krátkého potvrzení ve tvaru konstanty SAC. e) writeb pro zápis bitů do datové paměti S výhodou se tato funkce využívá pro zapisování dvou stavových zařízení, což jsou například spínaná světla, zapínání a vypínání topení a jiné. Potvrzení zprávy je opět realizováno konstantou SAC. 16

17 1.3.5 Instalační soubor Všechna zařízení zapojená k PLC je potřeba nějakým způsobem identifikovat, určit jejich parametry a dále s nimi pracovat. Právě k tomuto slouží soubor export.pub. Jeho struktura je pevně daná pro každou konfiguraci ovládaných prvků domu. Na jednom řádku se nachází jedno zařízení a jeho jednotlivé parametry jsou odděleny mezerami. První je název zařízení, poté následuje typ registru, CF, adresa, pozice bitu v registru, typ zařízení a nakonec informace o tom, zda je zařízení vstupní, výstupní nebo kombinace obou. UserBits R B UDINT PUB_INOUT system_showroom_alarm R B BOOL PUB_INOUT system_showroom_locked R B BOOL PUB_INOUT system_showroom_locking R B BOOL PUB_INOUT system_ag2_alarm R B BOOL PUB_INOUT system_ag2_locked R B BOOL PUB_INOUT system_ag2_locking R B BOOL PUB_INOUT Obrázek 9 - Ukázka struktury dat Tento soubor vygeneruje technik při prvotní instalaci systému inels pomocí grafického specializovaného software a dále zůstává neměnný. Ke změně dojde pouze, pokud si uživatel modifikuje instalovaná zařízení v domě. 1.4 Multimediální systém imm Jako jakousi nadstavbu platformy inels lze chápat systém imm, který přináší mnohem větší uživatelský komfort při ovládání domu. Nicméně systém imm je navržen jako samostatné řešení a jako takový slouží primárně pro přehrávání multimédií, procházení internetu a další běžné činnosti, jako je např. čtení ů. Systém tvoří samostatné PC, na nichž běží aplikace v prostředí operačního systému Linux. Každé takovéto PC může pracovat v režimu klient nebo server. Pokud pracují v režimu serveru, komunikují přímo s centrálou CU2-01M, a tudíž se systémem inels, jinak se dotazují serverového PC. V rámci systému je zavedeno jedno centrální úložiště dat, a to na serveru. V rámci systému imm lze také sledovat obraz z IP kamer a potažmo tento obraz nahrávat na pevný disk. Pokud to kamery umožňují, lze také ovládat jejich pohyb. Pro zajištění co největšího komfortu bydlení umí systém imm také ovládat domovní IP hlásky a případně spínat domovní dveře. Komunikace pro tato zařízení se realizuje pomocí protokolu SIP, samotný hlas se pak přenáší přes protokol VOIP. Dalším připojitelným zařízením je klimatizace, kterou lze také poměrně komplexně ovládat. Dají se nastavovat různé módy větrání, nastavení lamel a cirkulace vzduchu. Interně je pro komunikaci s klimatizací použit převodník Ethernet/RS

18 1.4.1 Konfigurační rozhraní systému imm Jak již bylo řečeno, systém imm je vlastně nadstavbou systému inels, proto nabízí poměrně komfortní ovládání zařízení. Pro konfiguraci různých zařízení v domě a správu celkové instalace bylo vytvořeno jednoduché webové rozhraní. V tomto rozhraní lze aktualizovat soubor export.pub, a tak reflektovat změny provedené na fyzické instalaci, nebo jen virtuálně přidávat a odebírat zařízení z místnosti. Místnosti lze také samozřejmě spravovat, tedy volně přidávat a odebírat. Příkladem místnosti je například obývací pokoj, kde lze mít nainstalovaná a přiřazená různá světla nebo spínané rolety. Pro ovládání multimedií slouží tzv. zóny. Jako zónu lze chápat například zapojenou televizi nebo hudební přehrávač. Jedna místnost tak může mít libovolný počet zón, ale každá zóna musí mít přiřazenu místnost, jinak není platná. Dalším prvkem, který stojí trochu mimo tyto dva, je ovládání klimatizace. Klimatizace jako taková je samostatný modul a lze ji přiřadit k místnosti. Grafická vizualizace klimatizace může mít čtyři podoby, které nabízí různé možnosti ovládání. Pokročilé funkce systému imm nabízejí také měření elektrické spotřeby. K tomu je určen speciální modul, jenž nabízí přehledný výpis spotřebované energie ve formě rozličných grafů. Po provedení všech změn v konfiguraci dojde k vygenerování xml souboru s přesně definovanou strukturou. Tento soubor se potom zpracuje v systému imm a pro každou místnost se vytvoří patřičné grafické elementy dle přiřazených prvků. Obrázek 10 Ukázka konfiguračního rozhraní systému imm 18

19 1.4.2 Ovládání spotřebičů MIELE Je-li v domě nainstalovaný systém imm a jsou-li připojeny některé domácí spotřebiče od firmy Miele k tomuto systému, lze je také přes něj ovládat. Jedná se zejména o různé pračky, kávovary, myčky nebo sušičky. Tato zařízení jsou připojena k internímu webovému serveru, se kterým komunikuje systém imm pomocí jednoduchých http dotazů. Serverové API obsahuje metody pro získání seznamu připojených prvků a jejich ovládání. 1.5 Celkové zapojení systému Již dříve zmiňovaná mobilní zařízení využívající operační systém Android umějí také komunikovat se systémem imm a jsou schopna ho ovládat, stejně tak jako napřímo či zprostředkovaně ovládat systém inels. Poněkud stranou stojí ovládání klimatizace a kamer, které mají samostatné řešení v mobilní aplikaci, zejména pak IP kamery. Pro ilustraci následuje schéma zapojení všech systémů, tedy inels a imm, do funkčního bloku. Pro propojení řídicí centrály se zbytkem systému je použit bezdrátový ethernet router. IP Kamery imm Server Televize Lampa imm Klient Televize Topení CU2-01M Žaluzie Klimatizace Mobilní zařízení Obrázek 11 Ilustrační zapojení všech prvků do funkčního celku 19

20 KAPITOLA 2 2. Operační systém Android Většina textu této kapitoly byla volně parafrázována z vývojového manuálu firmy Google [5]. Pro pochopení a porozumění funkčnosti aplikace jsou však tyto informace nezbytné. Uvedený popis obsahuje pouze stručné nastínění tématiky operačního systému Android, je ovšem nutný aspoň pro částečný vhled do jeho funkčnosti. Tento mobilní operační systém byl původně založen společností Android,Inc., kterou později koupila firma Google. O správu a rozvoj operačního systému se stará organizace Open handset aliance, která je volným sdružením 86 výrobců hardware a software a jejímž hlavním cílem je podpora otevřených standardů v mobilních zařízeních. Z toho důvodu byl systém Android uvolněn jako open-source pod Apache licencí, která definuje práva a povinnosti při používání software. Z otevřenosti systému vyplývá několik velkých výhod. Systém vyvíjí mnoho lidí, často bez nároku na honorář, a dochází tak k rychlému rozvoji a snadným úpravám. Další výhodou je přístup ke zdrojovým kódům systému a snadnému porozumění jeho jednotlivých funkcí. Právě díky otevřené povaze systému se tento operační systém dokázal během poměrně krátké doby rozšířit na velmi velkou škálu zařízení. V současné době se systém nachází v celé řadě přístrojů, jako jsou mobilní telefony, tablety či ledničky. Za tablet lze považovat ploché zařízení vybavené velkou obrazovkou, která zároveň slouží jako hlavní způsob ovládání. Modifikovanou verzi operačního systému například používá služba Google TV, která je schopna přenášet videa z internetu, dále pak nedávno oznámený projekt Android@Home, jenž nabízí ovládání přístrojů vybavených speciálním čipem, přes který tato zařízení komunikují po bezdrátové síti se systémem Android a lze je takto snadno ovládat přes mobilní zařízení. Nicméně právě díky obrovské roztříštěnosti zařízení a absenci nějakého referenčního prvku dochází ke komplikacím při rozvoji univerzálních aplikacích schopných fungovat na každém zařízení. Snahou o částečné řešení problému je již zakomponováno do systému, kdy se systém Android snaží nějakým způsobem abstrahovat fyzickou velikost displeje a rozdělit jej do určitých skupin. Detaily o tomto způsobu jsou v následujících kapitolách. O jistou formu standardizace se také pokouší společnost Google vydáváním mobilních telefonů, které by ostatní výrobci měli považovat jako referenční. Dalším krokem řešení obrovské škály zařízení je založení certifikačního programu pod názvem Android Compatibility Program, který definuje kompatibilní zařízení. U takovýchto zařízení je zaručeno, že půjdou spustit aplikace třetích stran a budou se chovat dle popisu v dokumentaci. Certifikace je bohužel dobrovolná, nicméně je zdarma. 20

21 2.1 Verze operačního systému a napojený ekosystém Od počátečního uvedení v roce 2007 prošel operační systém Android poměrně rozsáhlým vývojem a bylo vydáno několik významných vývojových verzí a několik méně významnějších, které pouze opravovaly nedostatky. První referenční a vůbec celosvětově první vydaný telefon měl operační systém ve verzi 1.5, která nesla označení Cupcake. Ta definovala standard, od kterého se systém dále modifikoval. Přinesla integrovaný internetový prohlížeč, hudební přehrávač, prohlížeč obrázků a mnohé další aplikace. Obrázek 12 Používané verze operačního systému v procentuálním vyjádření [6] Rozmach zařízení s větší obrazovkou donutil vývojáře k vytvoření plnohodnotného tabletího systému, neboť tehdejší čistě telefonní systém nevyhovoval požadavkům pro ovládání a rozložení ovládacích prvků na obrazovce. Výsledkem je verze operačního systému ve verzi 3.0 známá jako Honeycomb. Ta byla určena přímo pro zařízení s velkou obrazovkou. Bohužel zdrojové kódy nikdy nebyly uvolněny jako open source. Důvodem byla snaha společnosti Google zamezit instalování této verze operačního systému na nevhodná zařízení, například telefony. Díky této politice a funkčnosti na omezeném množství zařízení se tato verze nikdy nestala více rozšířenými. Zatím poslední vydanou verzí (4.0) v roce 2012 je verze nesoucí označení Ice Cream Sandwich, která přináší velké změny pro uživatele v grafickém rozhraní a sjednocuje jednotlivé verze operačního systému pro telefony a tablety. Její zdrojové kódy již byly uvolněny veřejnosti a považuje se za současný standard systému. Jedná se o velmi významnou verzi, jelikož umožňuje vývojářům aplikací mnohé nové možnosti. Mezi největší změny v API patří zahrnutí novinek z předchozí verze 3.0, tedy především práce s fragmenty. Další velkou změnu prodělal systém multimedií, který nyní nabízí mnohem širší možnosti použití. Přehled všech verzí operačního systému spolu s hlavními změnami ukazuje následující tabulka. 21

22 Označení/Číslo Datum vydání Popis změn První veřejná verze systému, přinesla nové grafické prvky Cupcake/1.5 Květen 2009 stejně jako nové element HorizontalScrollView Přidána podpora pro VPN sítě, Nové linuxové jádro, Donut/1.6 Říjen 2009 Nový systém pro detekci dotykových gest Přepracováno API pro správu aplikačních služeb, Úprava Eclair/ x Prosinec 2009 událostí pro odchytávání stisku kláves Možnost instalovat aplikace na paměťovou kartu, Froyo/2.2.x Květen 2010 Vytváření aplikací s administrátorskými právy Úprava grafického rozhraní, přidána podpora NFC a SIP Gingerbread/2.3.x Prosinec 2010 komunikace, vylepšeno NDK Verze určená pro tablety, přidány nové objekty typu Honeycomb/3.x Únor 2011 fragment, přidána nová notifikační lišta Action Bar Sjednocení telefonní a tabletí verze systému, představeno Ice Cream Sandwich/4.0 Říjen 2011 nové Social API určené pro práci se sociálními sítěmi Tabulka 4 Jednotlivé verze OS Android spolu s charakteristikou Společnosti Google se také podařilo vybudovat kompletní svébytný ekosystém okolo operačního systému Android, což umožnilo snazší přístup k systému pro běžného uživatele. Jeho součástí je propojení mobilního zařízení s ovým účtem, kdy uživatel má k u okamžitý přístup, a s dalšími službami Google. Nejvýznamnější součástí ekosystému je služba Google Play, které umožňuje stahování aplikací od různých vývojářů a tvoří tak ústřední bod pro shánění nových aplikací. Přes tuto službu se také řeší případné nové verze aplikace, kdy služba sama monitoruje vložené verze aplikace a dle potřeby je nabízí uživatelům ke stažení. Jsou zde také k dispozici různé statistiky vhodné pro vývojáře, například o počtu stažení aplikace nebo provozovaných verzí. 2.2 Architektura systému Architektura systému je založena na kompaktním linuxovém jádru, které obstarává nižší funkce systému, především ovladače pro jednotlivé moduly (kamera, wi-fi, čtečka karet, ), a běží na něm virtuální stroj pro chod jazyka Java zvaný Dalvik. Použité linuxové jádro není součástí hlavního vývojového cyklu tvořeného vývojářskou komunitou operačního systému Linux, ale je spravováno vývojáři systému Android. Z úsporných důvodů nejsou zahrnuty všechny knihovny, a proto nelze importovat aplikace napsané pro systém Linux. Jako verze programovacího jazyka Java byla zvolena otevřená varianta založená na projektu Apache Harmony. Bohužel projekt jako takový byl již pozastaven, a proto je další rozvoj pouze v režii správce systému Android. Virtuální stroj Dalvik byl specificky vytvořen pro potřeby mobilních zařízení a není kompatibilní 22

23 s jinými variantami virtuálního stroje. Při kompilaci využívá standardní javovský kompilovaný bytecode. Pod pojmem bytecode si lze představit sadu instrukcí pro virtuální stroj, které se získají po kompilaci souborů napsaných v jazyce Java. Tento kód se poté převede na speciální formát snadno zpracovatelný pro zařízení s omezenou kapacitou paměti a výkonem procesoru. Tímto formátem jsou soubory s příponou.dex, z anglického dalvik executable. Z tohoto právě plyne nekompatibilita s ostatními aplikacemi a vývojovými prostředími založenými na jazyce Java. Samotný virtuální stroj Dalvik se také podstatně liší od klasické javovského virtuálního stroje definovaného společností Sun, která jazyk Java představila jako první. Místo zásobníkové paměti využívá registrů. Tento přístup by měl urychlit práci s daty, nicméně výsledky jsou neprůkazné a oba systémy jsou na tom výkonově velice podobně. Aplikace Hlavní obrazovka Kontakty Telefon Prohlížeč Další předinstalované aplikace Aplikační rámec Správce activit Správce oken Správce balíčků Správci obsahu Systém pro vykreslení komponent Telefonní správce Správa polohy zařízení Správa zdrojů Notifikační správce Knihovny Prostředí OS Android Správce vykreslování Práce s multimédii SQLite Knihovny jádra systému OpenGL, ES FreeType WebKit Virtuální stroj Dalvik SGL SSL libc Linuxové jádro Ovladač displeje Ovladač fotoaparátu Ovladač flash paměti Spojení meziprocesní komunikace Ovladač klávsesnice Ovladač WiFi Ovladač zvuku Správa napájení Obrázek 13 - Schéma vnitřního uspořádání OS Android [7] Systém Android je schopen pracovat jak na energeticky úsporných procesorech typu ARM, tak i na procesorech založených na architektuře x86. Abstrakci nad nutností použít speciální instrukční sadu dle typu procesoru zajišťuje právě javovský virtuální stroj. Většina aplikací je proto napsána v programovacím jazyce Java. Pro výpočetně náročné procesy je možno programovat aplikace v jazyce C či případně C++. Je nutné zmínit, že se zatím nedají psát plnohodnotné aplikace pouze v těchto jazycích. Pro svou funkčnost stále potřebují mít 23

24 klasicky napsanou aplikaci v jazyce Java, která bude spouštět kód v jazyce C. Tento kód funguje jako knihovna, jejíž funkce lze volat přímo z javovské aplikace. Při překladu jazyka C je nutno použít nástrojů uvolněných společností Google pod názvem NDK (Native development kit). Ty obsahují speciální knihovny a skripty pro správné zkompilovaní. Zde se naráží na problém rozdílných instrukčních sad procesorů, a proto je nutné kompilovat proti předem danému typu procesoru. Samotné aplikace potom běží v tzv. sand-box režimu, kdy nemají přístup k ostatním částem systému a ani k ostatním aplikacím, nicméně existují prostředky pro aspoň částečnou komunikaci mezi aplikacemi. Použité linuxové jádro pracuje v režimu více uživatelů, kde je každá aplikace maskována jako jiný uživatel. Každá aplikace tudíž dostane interní identifikační číslo, které není sama schopna zjistit. Spuštěná aplikace potom běží v samostatném procesu a je jí přidělena nová instance virtuálního stroje, takže není schopna adresovat nějaký jiný paměťový prostor. Pokud aplikace vyžaduje přístup k nějakým systémovým komponentám, musí si vyžádat speciální povolení. Seznam těchto povolení se potom zobrazuje při instalaci aplikace a uživatel ho musí odsouhlasit. Tímto způsobem se zabezpečuje nechtěné chování aplikací. Bohužel v současné době se tento způsob ochrany ukázal jako nedostatečný a aplikace se začínají filtrovat už při publikaci na službě Google Play. 2.3 Struktura aplikací Aplikace vytvořené pro systém Android se skládají z několika základních funkčních bloků, které tvoří různé vstupní body. Systém tedy může pomocí těchto bodů informovat aplikaci o různých stavech zařízení, předávat zprávy z jiných aplikací a mnohem více. Každý takovýto blok má jiný účel a nutně nemusí být přístupný událostem vyvolaným uživatelem. Aplikace proto nemají jediný spouštěcí bod na rozdíl od klasických javovských, které mají hlavní funkci main (). Aplikace 1 Výzva ke spuštění Přijatá data Spuštění aplikace Operační systém Android Odeslaná data Aplikace 2 Obrázek 14 Ukázka spouštění částí jiných aplikací Systém dokonce dovolí spouštět i součásti jiných aplikací, jak je naznačeno viz Obrázek 14. To se sice neděje přímo z aplikace, protože ta běží nezávisle, ale aplikace informuje systém o záměru spustit část jiné aplikace a ten to za ni provede. Při ukončení druhé aplikace může volitelně vrátit nějaká data a ta jsou přijata v první aplikaci. Tímto způsobem je dosaženo značné 24

25 flexibility celého systému a odpadá nutnost tvořit každou součást aplikace samostatně. Jsou dodrženy i navržené bezpečnostní mechanismy, protože meziprocesní komunikaci obstarává samotný systém. Komponenty, které lze takto spouštět a zároveň jsou i vstupními body pro systém a můžou být asynchronně volány, jsou tzv. Activities, Services a Broadcast Receivers. Další blokem jsou tzv. Content providers, které slouží pro spravování obsahu aplikace Charakteristika komponenty Activity Tato komponenta reprezentuje jedno viditelné okno pro uživatele. Okno může být roztaženo přes celou obrazovku, nebo být plovoucím dialogem. Aktivitám lze snadno nastavit grafickou podobu pomocí předem definované metody setcontentview(), která načte a zpracuje xml soubor. Jeho struktura a vlastnosti budou popsány v dalších částech. Z výkonových důvodů ovšem musí být soubory předkompilovány, a proto nelze použít libovolný externí xml soubor. Každá aplikace se většinou skládá z více aktivit, které mohou být navzájem nezávislé. Každá z nich je schopna spouštět jinou. Důležitou aktivitou je aktivita, která se spustí jako první a je označována jako hlavní. Takovouto aktivitu uživatel uvidí při spuštění aplikace. Pro správu spuštěných aktivit slouží tzv. Back Stack. Jedná se vlastně o zásobník typu LIFO ( last in, first out), ve kterém je uložena informace o spuštěných aktivitách v aplikaci. Pokud se pustí nová aktivita, je starší zastavena, a nová se přesune na první místo v zásobníku. Ukončí-li uživatel aktuální aktivitu, vrátí se k předchozí, která se obnoví ze zásobníku. Spuštění nové aktivity První aktivita Druhá aktivita První aktivita Viditelná aktivita První aktivita Vrácení se zpět Obrázek 15 Ukázka funkce zásobníku aktivit Během celého tohoto procesu jsou všechny aktivity informovány o svém stavu pomocí zpětného volání systému. Tyto funkce jsou velice důležité, neboť vytváří celý životní cyklus aktivity a každá aplikace s nimi musí počítat. Aktivita také obdrží informaci, když dojde k otočení zařízení do jiné polohy. V tuto chvíli je celá aktivita zastavena a zahozena. Dojde k vytvoření nové instance aktivity, která znovu projde celým svým životním procesem. Toto může způsobit někdy problém, neboť veškeré reference na předchozí aktivitu jsou již neplatné a některé objekty tudíž 25

26 nemusí fungovat, proto musí dojít k řádnému uvolnění referencí při ukončení aktivity. Tento přístup je také nezbytný pro efektivní správu paměti. Pro vytvoření nové aktivity je třeba vytvořit třídu dědící ze třídy Activity, která je součástí systémové knihovny. Ta má implementované veřejné metody životního cyklu aktivity, které se dají přepsat, nicméně je nutné volat i mateřské metody pomocí volání funkce super (). Společným předkem všech aktivit je rozhraní Context, které umožňuje aplikaci přístup k různým systémovým komponentám, jako například správce senzorů či lokace zařízení. Základní třídu, od které dědí všecky další implementace, poskytuje systém Android. Obsahuje implementace spouštění jiných aktivit či registraci komponenty Broadcast Receiver. Kontext se proto používá vždy, když je potřeba přistupovat k systémovým zdrojům. Existuje proto více implementací, jako je aplikační kontext nebo kontext přiřazený ke grafické komponentě. Někdy se ukazuje jako poměrně obtížné s ním manipulovat, například když potřebuji získat aplikační zdroje mimo aktivitu. Důrazně se nedoporučuje vytvářet lokální objekt kontextu odvozený od aktivity, protož ta může být kdykoliv zastavena a uvolněna z paměti, tudíž by reference neplatila. Místo toho je vhodnější použít aplikační kontext, který je stejný po celou dobu chodu aplikace. Stav aktivity lze rozdělit do třech částí běžící, pozastavená a zastavená. Běžící aktivita se zobrazuje na obrazovce a má přímý vstup pro uživatelské události. Pozastavená aktivita je taková, která je překrytá nějakou jinou aktivitou, například dialogovým oknem. Takováto pozastavená aktivita normálně funguje a je plně držena v paměti zařízení. Zastavená aktivita je kompletně překryta novou aktivitou a je přesunuta do pozadí. Aktivita je stále držena v paměti a udržuje si nastavené parametry. Tento stav se může změnit při nedostatku paměti, kdy systém může zastavené aktivity ukončit buď zavoláním jejich finish () metod, nebo násilným ukončením procesu, ve kterém aktivita běží. Při vytvoření aktivity v systému se zavolá metoda oncreate (). V této metodě by se měl definovat grafický vzhled aktivity a inicializovat základní komponenty. Dále se zavolá metoda onstart (). Tato metoda signalizuje, že aktivita je těsně před zviditelněním a je možné provést úvodní konfiguraci zobrazení. Dále se zavolá metoda onresume (), která slouží pro notifikaci, že aktivita již běží a je viditelná uživateli. Pokud se aktivita ukončuje z jakéhokoliv důvodu, například uživatelskou událostí nebo nedostatkem paměti, zavolá se metoda onpause (). V této metodě by mělo dojít k uložení všech potřebných informací spojených se stavem aktivity, například různé uživatelské nastavení, protože není zaručeno opětovné spuštění aplikace. Z principu funkce metody onresume a onpause mohou být volány velice často, proto by kód prováděný v těchto metodách neměl být výpočetně náročný. Pokud se aktivita stane neviditelnou, zavolá se metoda onstop (). Poslední metodou z životního cyklu aktivity je ondestroy (), která se zavolá při odstranění aktivity z paměti. Zde by se měla uvolnit reference 26

27 na všechny velké objekty v paměti, resetovat statické proměnné a případně ukončit běžící vlákna. Pomocí výše zmíněných metod lze definovat tři různé programové smyčky, které se můžou vyskytnout během života aktivity. První je projití celkovým životním cyklem, kdy se aktivita spustí metodou oncreate a ukončí metodou ondestroy. Další smyčkou jsou viditelné metody onstart a onstop, které se mohou volat mnohokrát za život aktivity, a je vhodné zde registrovat asynchronní události, které mají dopad na grafické komponenty aktivity. S voláním této smyčky souvisí i metoda onrestart (), jež je volána právě v těchto případech a předchází metodu onstart. Pokud je aktivita pozastavena, prochází pouze voláním metod onresume při spuštění a onpause při ukončení. Jak již bylo zmíněno, při změně orientace zařízení dojde ke znovuvytvoření aktivity. Občas je nutné uložit nějaké informace týkající se aktuálního stavu aktivity. K těmto účelům slouží metody onsaveinstance (), která slouží pro uložení dat, a onrestoreinstancestate(), pomocí níž se dají data zpětně načíst a zpracovat. Znovu spuštění aktivity onrestart oncreate onstart onresume Chod aktivity onpause onstop ondestroy Vrácení se k aktivitě Spuštění aktivity Zastavení aktivity Obrázek 16 Životní cyklus aktivity S pozdější verzí systému Android 3.0 Honeycomb bylo představena i nová komponenta tzv. Fragments. Fragmenty lze chápat jako menší objekty, ze kterých se mohou skládat aktivity. Hlavním důvodem, proč se tyto objekty vytvářely, je implementace zpětného volání během životního cyklu aktivity. Tyto objekty mají tedy také svůj životní cyklus obdobný jako aktivita, kromě několika metod nutných pro jejich chod. Modulárnost fragmentů umožňuje snadné vytvoření aplikací kompatibilních jak s mobilními telefony, tak s tablety. Fragmenty mají svůj vlastní zásobník změn, nad kterým má programátor plnou kontrolu na rozdíl od aktivit, a proto jsou v tomto ohledu flexibilnější než aktivity. Většina systémových komponent, jako jsou dialogy, byly přepracovány a dle doporučení dokumentace se má používat nová fragmentová verze. K tomu byla vytvořena kompatibilní knihovna pro zaručení funkce i na starších verzích systému. 27

28 onactivitycreated onstart Fragment byl odebrán nebo uživatel vyvola událost zpět Chod onresume onpause onstop fragmentu oncreateview oncreate Fragment se vrátil ze zásobníku na obrazovku ondestroyview ; ondestroy onattach ondetach Přidání fragmentu Obrázek 17 Ukázka životního cyklu fragmentu Odebrání fragmentu Charakteristika komponenty Service Komponentu Service lze chápat jako klasickou službu určenou pro provádění dlouhotrvajících operací. Její koncept se podstatně liší od principu aktivit, protože tyto služby mohou běžet na pozadí zařízení, i když je ukončena poslední aktivita aplikace. Takováto funkce je velice žádoucí například při přehrávání hudby nebo síťové komunikaci. Obecně lze spouštět služby i z jiných aplikací a tímto způsobem z ní získávat data, nicméně tuto funkci lze při definování služby vypnout a nastavit ji jako soukromou. V základním provedení běží služby v procesu aplikace, tudíž při provádění náročných operací by mohlo dojít k blokování uživatelského vstupu a z pohledu uživatele by aplikace vypadala zastavená. Dokonce, pokud by doba provádění operace přesáhla vymezený čas 5 sekund, by došlo k vyvolání systémové výjimky a uživateli by se zobrazil dialog o neaktivitě aplikace. Proto je vhodné v těchto případech použít separátní vlákno, které těmto problémům předchází. Služby lze v operačním systému rozdělit na dva typy spuštěná a navázaná. Spuštěná služba je schopna běžet i po zničení objektu, který ji spustil, a pokud není ukončena, bude běžet neustále. Typickým příkladem je použití při časově náročné operaci, ze které není třeba vracet žádnou návratovou hodnotu. Vázané služby se využívají pro složitější procesy, kdy je potřeba průběžně komunikovat mezi službou a aplikací. Takovéto služby běží tak dlouho, dokud jsou nějaké aktivity na ně navázány. K jedné takovéto službě může být připojeno více klientů. Pokud se odpojí poslední klient, služba se ukončí. Nejčastěji se však používají oba způsoby zkombinované dohromady. Tedy spuštění služby příkazem startservice () a připojení klientů pomocí příkazu bindservice (). Takto volaná služba se ukončí pouze za předpokladu, že se odpojí všichni připojení klienti a služba je ukončena pomocí příkazu stopservice (). 28

29 Stejně jako aktivity i služby mají definované metody pro zpětné volání, pomocí kterých systém informuje o stavu služby. Tyto metody také definují životní cyklus služby. Všechny metody jsou stejné pro oba typy služeb. V případě spuštěné služby se jich část pouze neimplementuje. Při vytvoření služby se zavolá metoda oncreate (), ve které se typicky provádí první inicializace. Tato metoda se zavolá pouze jednou pro danou instanci služby. Opakem metody oncreate je metoda ondestroy (), která se volá při ukončení služby a stejně jako u aktivity by se zde měla uvolnit data z paměti či ukončit spuštěná vlákna. Při spuštění služby pomocí příkazu startservice se v nově vytvořené službě zavolá metoda onstartcommand (), ve které se provádí hlavní činnost služby. Po ukončení činnosti se služba může ukončit pomocí zavolání stopself (). Pokud externí komponenta naváže službu, tak se zavolá metoda onbind (), která vrací rozhraní pro komunikaci mezi službou a klienty. Tato metoda musí být vždy implementována, ale pokud služba nepodporuje navazování klientů, nemusí metoda vracet nic. Při odpojení všech klientů se volá metoda onunbind (), kde se musí ošetřit asynchronní ukončení služby. Spuštění služby Navázání služby oncreate oncreate onstartcommand onbind Chod služby Komunikace s klienty Služba se sama ukončila nebo byla ukončena externím voláním onubind ondestroy ondestroy Ukončení služby Ukončení služby Obrázek 18 Životní cyklus služeb. Vpravo spouštěné a vlevo navázané služby Charakteristika komponenty Broadcast Receiver Tuto komponentu lze chápat jako příjemce zpráv vysílaných z různých zdrojů. Těmito zdroji můžou být systémové zprávy nebo zprávy zasílané aplikacemi. Příkladem systémových zpráv 29

30 může být například informace o nízkém stavu baterie, vypnutí zvuku nebo zapnutí telefonu. Pro příjem takovýchto zpráv je většinou nutné, aby si aplikace vyžádala speciální práva. Receivery jsou zamýšleny pouze jako informační vstupy do aplikace, a proto by se zde neměl provádět žádný výpočetně náročný kód. Není vhodné ani spouštět asynchronní události, neboť po ukončení životního cyklu receiveru se jeho proces ukončí a uvolní se veškerá asociovaná paměť. Broadcast receivery mají pouze jednu veřejnou metodu, která informuje o jejich stavu onreceived (). Systém zavolá vždy tuto metodu, pokud receiver obdrží příslušnou zprávu. Každému receiveru lze nastavit filtr zpráv a tím určit, o jaké zprávy bude mít zájem. Systémové komponenty si musí receivery zaregistrovat pomocí metody registerreceiver () a stejně tak odregistrovat při ukončení svého životního cyklu zavolat metodu unregisterreceiver (). Pokud by nedošlo k odregistrování receiveru, systém by to vyhodnotil jako únik paměti a zahlásil systémovou chybu Charakteristika komponenty Content Provider Jak již bylo řečeno, tato komponenta slouží pro správu a ukládání dat aplikace. Variabilita implementace umožňuje za úložný prostor zvolit velice různorodá uložiště. Častým příkladem je SQL databáze, ale zdrojem může být i webové služba nebo pevný disk. K těmto datům lze pak přistupovat i z jiných aplikací. Takto lze například získat přístup ke všem fotografiím uloženým v mobilním zařízení. Samozřejmě aplikace musí mít nastavena příslušná práva pro čtení dat. Navenek se struktura dat jeví podobná klasické tabulkové struktuře z relačních databází, čili každý záznam má svůj řádek a atributy záznamu jsou uloženy ve sloupcích. Pro jasnou identifikaci musí mít každý Content Provider určenou jasnou adresu, té se říká autorita a dle všeobecně přijímaných konvencí se definuje jako řetězec složený z názvu balíčku aplikace a názvu Content Provideru. V systému Android se využívá unikátní content URI, pocházející z anglického Uniform Resource Identifier a definující adresu v rámci různých aplikací. Zde se používá ve smyslu získání dat. Na konci adresy se nacházejí klíčová slova, která reprezentují názvy dat, jež chceme z komponenty získat nebo zapsat. URI pro získání dat má následující strukturu: content://autorita_content_provideru/klicova_slova Tabulka 5 Ukázka URI pro získání dat z komponenty Content Provider Každá instance této komponenty musí mít implementovánu sadu metod pro provádění transakcí a práci s daty. Metody lze rozdělit na zapisovací a čtecí. Čtecí metodou je query (), která vrací jako výstup z metody objekt Cursor. Kurzor lze chápat jako rozhraní obsahující informaci o uložených datech. Tato metoda má sadu vstupních parametrů, pomocí kterých lze přesně specifikovat požadovaná data. Pomocí kurzoru lze pak k datům přistupovat a číst je. 30

31 Metod pro zapisování je více. Pro vložení nových dat slouží insert (), data lze poté modifikovat pomocí metody update () a mazat přes delete (). Zapisování a změna již uložených data se provádí pomocí tzv. Content values, které jsou parametry patřičných metod. Content values je vlastně pole párů hodnota a název sloupce, které je schopna aplikace rychle zpracovat a uložit. Z principu funkce Content Provideru mohou být tyto funkce volány z více vláken najednou, a proto je nutné, aby byly metody zabezpečeny proti uváznutí programu. Stejně jako u již dříve popisovaných komponent má i Content Provider zpětné volání při vytváření nové instance objektu. Touto metodou je oncreate (), která se volá pouze jednou. Typicky se zde inicializuje databáze, kde se vytvoří její struktura, nebo v případě změny verze databáze dojde k vymazání a novému vytvoření. Stranou od již zmíněných metod stojí metoda gettype (), která vrací tzv. MIME typ dat. Zkratka pochází z anglického Multipurpose internet mail extension a umožňuje definovat různé druhy dat. Vznikla z důvodu nutnosti posílat nejrůznější multimediální přílohy v ech. Datové typy jsou definovány pomocí mezinárodních norem a je tak garantováno, že i různá softwarová řešení budou schopna spolu komunikovat. Tato metoda sice není povinná, nicméně při implementaci Content Provideru, který má například sloužit jako zdroj obrázků, je nutno ji implementovat Vlastnosti objektu Intent Objekty typu Intent slouží pro spouštění a spojování různých komponent. Lze pomocí nich vyvolávat různé asynchronní události, například zasláním do Broadcast Receiveru. Objektem Intent lze spouštět komponenty aktivity pomocí metody startactivity nebo navázat služby pomoci bindservice. Právě objekt Intent je prostředníkem mezi různými komponentami a zabezpečuje výměnu dat mezi nimi. Pro služby a aktivity existují dva typy objektů, každý s jinou nastavenou akcí. Prvním typem akce je akce View, která spouští aktivity. Druhým typem je pak Send, jež slouží pro zasílání dat. U každého objektu Intent se dá také specifikovat, co chce spustit nebo jaká data nese, aby mohl případný příjemce správně zareagovat. Veškerá meziaplikační komunikace probíhá pouze přes Intenty. Obdobou Intentu pro komponentu Content Provider je objekt Content Resolver, který se stará o veškerou komunikaci s Content Providerem Soubor AndroidManifest.xml Každá aplikace musí mít při kompilaci přítomný tento soubor, protože ten definuje, které třídy v balíčku reprezentují aktivity a další komponenty. Je jakýmsi pomyslným lepidlem, které spojuje vše dohromady a tvoří tak kompaktní celek. Proto má pevně danou strukturu, kterou je třeba dodržet. Kromě definic se zde však také vyskytuje mnoho dodatečného nastavení. Lze zde 31

32 například definovat potřebné knihovny, podporované velikosti displeje nebo práva pro aplikaci. Ta jsou velice podstatná, neboť definují, kam všude bude mít aplikace přístup. Soubor také nese velmi důležitou informaci o vybrané verzi systému, proti jejímuž API se vytvořila aplikace. Týká se to hlavně pozdějších verzí systému Android, které musí ke starším aplikacím přistupovat rozdílně. Všechny výše zmíněné komponenty mají svůj obraz v tomto souboru, jak ukazuje následující tabulka: Název komponenty Activity Service Broadcast Receiver Content Provider 32 Obraz v xml souboru <activity> <service> <receiver> <provider> Tabulka 6 Názvy komponent Každá komponenta však ještě může mít další nepovinná nastavení, která specifikují její vlastnosti a chování v systému. Například lze takto aktivitě nastavit, jaké objekty typu Intent bude přijímat nebo zda bude mít vynucený pouze jeden režim displeje. Existuje zde velmi velké množství různých kombinací pro každou komponentu, a proto je nutné postupovat dle dokumentace, neboť změny zde provedené mají velký vliv na chování celé aplikace. <application android:name="itpapplication" android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/theme" > <provider android:name="com.itp.database.databaseprovider" android:authorities="com.itp.databaseprovider" /> <activity android:name=".activity.activityregister" android:screenorientation="landscape" > </activity> <activity android:name=".activity.activitymain" android:screenorientation="landscape" > <intent-filter> <action android:name="android.intent.action.main" /> <category android:name="android.intent.category.launcher" /> </intent-filter> </activity> Obrázek 19 Ukázka souboru manifest přímo z aplikace Na Obrázek 19 je ukázka souboru manifest přímo z aplikace, která je předmětem této práce. Definičnímu prostoru pro aktivity musí vždy předcházet prostor pro definici aplikace. Zde se může volitelně upřesnit třída v tagu android:name, která bude reprezentovat aplikaci a v které

33 je třeba provádět nějaké operace. Tento princip je stejný i u aktivity. Dále následují tagy android:icon a android:label, jež slouží pro určení ikony a názvu aplikace v zařízení. Poslední je tag android:theme, který definuje souhrn grafických vlastností aplikace zvaných téma. Prostor při části intent-filter v definici aktivity slouží pro nastavení filtrování zpráv aplikaci. Zde konkrétně ukázaný nastavuje první aktivitu, která bude spuštěna po startu aplikace Zdroje dat aplikace Název složky/idenfikátoru animator anim color drawable layout menu values xml Vlastnosti Konfigurační soubory pro definici animací pomocí tzv. Property Animations, představeného ve verzi systému 3.0 Honeycomb. Konfigurační soubory pro definici animací pomocí staršího animačního systému, definující vlastnosti a změny jednotlivých komponent. Definice pro barevné zobrazení některý grafických elementů. Například se zde definují různé barvy pro text tlačítka při klidovém stavu a stisku. Zde se ukládají všechny grafické podklady pro aplikaci. Může jít o již zmiňované bitmapové obrázky nebo o vytvořené grafické objekty pomocí definice v xml souborech. Soubory definující grafický vzhled aplikace. Soubory určující jak bude vypadat vzhled aplikačního menu. Lze například určit ikonu, text nebo kategorii menu. Složka pro ukládání všech primitivních typů dat jako jsou texty, čísla, rozměry elementů nebo jejich styly. Jakékoliv libovolné xml soubory, které mají být programově přístupné v aplikaci. Tabulka 7 Typy složek pro datové zdroje Pro správný chod potřebuje aplikace kromě zdrojových a konfiguračních kódů programu grafické podklady a různé texty. Zdroje dat pro aplikaci lze rozdělit na více typů. Prvním jsou konfigurační xml soubory, které například definují grafický vzhled aktivit nebo různé stylové elementy. Druhým typem jsou multimediální data, ať už zvuky, videa nebo obrázky. Pro obrázky je vhodné zvolit formát png, pro který je systém optimalizován. Hlavní předností formátu png je přítomnost alfa kanálu, tedy průhlednosti, která velice ulehčuje vývoj grafické podoby aplikací. Jedním z typů můžou být jakákoliv data uložená ve své originální podobě. Označují se jako tzv. raw a lze k nim velice snadno přistupovat pomocí zabudovaného rozhraní. Speciálním typem dat jsou identifikátory grafických komponent, které slouží pro jejich 33

34 vyhledání v rámci aktivity nebo grafické komponenty. Každý takovýto typ má přiřazené označení a musí být v předem definované složce. Pro přístup ke zdrojům slouží vygenerovaná R třída, která vlastně obsahuje pouze identifikátory souborů ve formě čísla. Pomocí těchto čísel se dá za běhu programu ke zdrojům přistupovat. R třídu vytvoří kompilátor systému při vytváření aplikace. Tento proces je plně automatizovaný a nepotřebuje uživatelský zásah. Operační systém Android má integrovanou pokročilou správu zdrojů a nabízí její velice snadnou údržbu. Všechny zdroje lze rozdělit do několika kategorií rozdělených podle kvalifikátorů, které lze mezi sebou kombinovat, a systém sám vybere vhodné dle typu a konfigurace zařízení. Například textové zdroje se ukládají do několika složek rozdělených podle patřičných jazyků a při spuštění aplikace dojde k automatickému výběru nejvhodnějšího. Obdobně se filtruje grafické rozložení aplikace podle velikosti displeje nebo aktuální polohy zařízení. Pro velikost displeje je zavedeno několik kategorií. Dalším důležitým parametrem displeje je jeho hustota pixelů. Každý displej má dán maximální počet pixelů, který je schopen vykreslit. Tato hodnota udává jeho rozlišení. Většina zařízení, která označujeme jako tablet, má typické rozlišení 1024x600 nebo 1280x800. Různě veliké displeje se stejným rozlišením proto musejí mít jinou hustotu pixelů na jednu měrnou jednotku, v tomto případě se používají palce a jednotkou je dpi z anglického dots per inch. Pro ošetření těchto vlastností displeje byla zavedena umělá jednotka dip nebo zkráceně dp, která definuje, jak se bude měnit hodnota parametru v závislosti na hustotě displeje. Jako referenční hustota se bere hustota pixelů okolo hodnoty 160 dpi a pokud je hodnota větší či menší, je jí přiřazen jiný kvalifikátor. Název kategorie (anglická varianta) Přibližná úhlopříčka displeje v palcích Typická hustota displeje Malé (small) dpi Normální (normal) dpi Velké (large) dpi Extra velká (xlarge) 7 - x 160 dpi Tabulka 8 Kvalifikátory založené na vlastnostech displeje 2.4 Grafický systém Všechny grafické komponenty v systému Android lze rozdělit na dva typy View a ViewGroup. View elementy reprezentují skutečné grafické objekty, které vykreslují například text nebo obrázek či komplexnější objekty jako digitální hodiny. Běžně se takové prvky nazývají widgety. Elementy ViewGroup slouží jako kontejnery pro definování vlastností widgetů a jejich umístění na obrazovce. Existuje více druhů těchto prvků a každý je určen pro jiné použití. Například komponenta HorizontalScrollView slouží pro horizontální posun vložených grafických prvků. Je odvozena od jiné komponenty LinearLayout, která řadí 34

35 prvky za sebe buď horizontálně, nebo vertikálně. Další důležité kontejnery, od kterých se odvozuje řada dalších, jsou RelativeLayout a FrameLayout. RelativeLayout, jak už název napovídá, slouží pro umístění prvků relativně vůči sobě nebo kontejneru, kdežto FrameLayout umisťuje prvky podle nastavených atributů vždy ke své hraně nebo na střed. Tento element by měl obsahovat pouze jeden prvek. ViewGroup View ViewGroup View View View Obrázek 20 Ukázka hierarchie grafických komponent [8] V předchozí kapitole byl detailně popsán princip správy aplikačních zdrojů. Jedním ze zdrojů jsou definiční xml soubory pro grafické rozhraní. Každý řádně označený element v tomto xml souboru reprezentuje jeden grafický prvek. Těmto prvkům lze nastavovat parametry pomocí předem definovaného jmenného prostoru. Pokud se jedná o systémové komponenty, je potřeba uvést jedná-li se o nově vytvořené komponenty, je nutné uvést správnou definici. Některé parametry jsou povinné a pro správné zkompilování aplikace je nutné, aby byly vyplněny. Například se jedná o parametry definující šířku a výšku komponenty. <LinearLayout xmlns:android=" android:layout_width="match_parent" android:layout_height="match_parent" android:gravity="center" android:orientation="vertical" > <LinearLayout android:layout_width="wrap_content" android:layout_height="wrap_content" android:orientation="horizontal"> <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:textsize="26sp" android:gravity="center" android:text="@string/demoexpire"/> Obrázek 21 Ukázka použité xml souboru s definicí elementů 35

36 Všechny grafické komponenty mohou samozřejmě být vytvořeny i programově za chodu aplikace, ale není to příliš pohodlné, neboť se musí veškeré úvodní konfigurace komponent provést ve zdrojových datech, což nepřispívá ke snadné čitelnosti zdrojového kódu Grafická komponenta ListView Vlastní implementace ListView je poměrně komplexní záležitost, a proto zde nastíním jen základní princip tvorby grafických elementů. Velice důležitou grafickou komponentou je seznam prvků řazených vertikálně, protože v mobilních telefonech není tolik dostupného místa na displeji a často je nutné vypsat nějaká data přehledně a jednoduše, jako například příchozí textové zprávy. Komponenta ListView toto nabízí, nicméně nenabízí jen pouhý seznam. Implementace této komponenty zaručuje, že v paměti zařízení se udržují jen právě zobrazené prvky, což má u velice dlouhých seznamů nebo graficky náročných prvků značnou výhodu, neboť seznam při posouvání funguje na první pohled plynuleji, protože má k dispozici více volné paměti. Toho se velice využívá u mobilní aplikace pro ovládání domu, neboť hlavní obrazovka je z velké části tvořena jen ListView a všechny ovládané prvky jsou jako položka seznamu. Nepřítomnost všech grafických reprezentací prvků seznamu je hlavní rozdíl například od komponenty LinearLayout, která také nabízí jednoduchý seznam řazený vertikálně, ale všechny prvky jsou najednou v paměti a můžou značně zpomalit chod aplikace. Z těchto důvodů má komponenta ListView poměrně specifický způsob plnění dat a jejich správu. Používají se tzv. adaptéry, které mají v sobě integrovánu sadu metod pro vytváření a správu grafických komponent v seznamu, a proto každé vlastní řešení musí tyto metody implementovat. V rámci seznamu se rozdělí grafické reprezentace jednotlivých prvků dle jejich typu a poté se určuje, jestli se prvek vykreslí, nebo se použije již recyklovaný. Existují dva předem definované typy adaptérů pro načítání z pole prvků a pro načítání z databáze. Oba jsou rovnocenné a každý má své typické využití Menu systém Většina současných mobilní zařízení určených pro systém Android je vybavena speciálním tlačítkem, které po stisku vyvolá aplikační menu. V tomto menu se nacházejí širší možnosti použití aplikace a typicky se zde zobrazuje zástupce pro přechod do nastavení aplikace. Dalším typem menu jsou tzv. kontextová menu, která se objeví, pokud uživatel dlouho podrží prst na nějaké komponentě. Většinou se zde zobrazují věci spjaté s danou komponentou. Tato menu se dají vytvořit pomocí xml souborů z aplikačních zdrojů, a nabízejí tak velice flexibilní možnosti použití. Pro každý typ menu existují patřičné veřejné metody ve třídě Activity, které jsou volány, pokud se menu vytváří ( oncreateoptionsmenu() nebo oncreatecontextmenu() ), 36

37 nebo pokud uživatel vybral nějaký prvek z menu ( onoptionsitemselected() nebo oncontextitemselected() ). 2.5 Vstupní uživatelské události Pokud se uživatel dotkne obrazovky na nějakém místě, systém Android vyhodnotí tento dotyk a pokud se zobrazuje na místě doteku nějaká grafická komponenta, předá informaci o dotyku komponentě. Všechny grafické komponenty mají implementovánu metodu ontouch(), která se volá po jejich dotyku. V rámci systému se rozlišuje několik typů dotyku kliknutí, dvojité kliknutí, dlouhé podržení a mnoho dalších. Dokonce lze definovat i nová gesta, která se dají uložit, a uživatel pomocí nich může napříště aplikaci ovládat. Zde je nutné poznamenat, že každá implementace grafického elementu si rozlišuje svoje uživatelské události a nemusí na některé odpovídat. Protože by bylo velice nepraktické přepisovat ontouch metodu každého grafického prvku pro získání informace o události, má každý prvek definované rozhraní, pomocí kterého se lze k události snadno dostat. Takovým typickým rozhraním je OnClickListener pro příjem událostí typu kliknutí nebo OnTouchListener pro příjem události obecného dotyku. 2.6 Úložiště dat Pro uložení různých uživatelských preferencí a nastavení má systém Android implementovaný jednoduchý ukládací systém založený na dvojicích klíč-hodnota. Základní třídou, která řeší ukládání, je SharedPreferences. V rámci aplikace se rozdělují preference na základní a preference přiřazené k aktivitě, ke kterým lze přistupovat jen a pouze z dané aktivity, respektive jejího kontextu. Tyto preference slouží pro uložení jednoduchých datových typů, jako jsou řetězce nebo čísla, pro komplexnější data je nutné využít relační databázi nebo serializovaná data uložit do paměti zařízení. V mobilní aplikaci se preference používají například pro uložení informace o IP adrese serveru nebo nastaveném barevném schématu aplikace. Základní systémový balíček knihoven obsahuje plnou implementaci SQLite relační databáze [10], která je určena pro použití v zařízeních s malým výpočetním výkonem a operační pamětí. Jedná se o otevřené řešení databáze, o jehož rozvoj se stará konsorcium předních výrobců software a hardware. Jeho hlavní devizou je schopnost běžet bez serverového procesu, tudíž jsou všechny funkce jako čtení a zápis konána v jednom procesu. Data jsou uložena v jednom souboru na disku zařízení nehledě na počet tabulek. Soubory jsou typicky veliké kolem 200 kb, což přináší obrovskou úsporu místa na disku zařízení. V systému Android byla vytvořena třída SQLiteOpenHelper usnadňující správu databáze v zařízení, která sama ošetřuje fyzické napojení na databázi. Pro správnou funkci je nutné definovat verzi databáze a její název. Databáze je nutné verzovat, neboť při postupném vývoji aplikace může dojít k přidání nebo 37

38 naopak odebrání sloupce či tabulky a v tom případě by databáze nebyla kompatibilní s předchozí verzí. Pro tyto případy a pro variantu prvního použití databáze jsou implementována zpětná volání pomocí metod oncreate () a onupdate (). Ve funkci oncreate se typicky vytváří tabulky a sloupce v nich pomocí vykonávání příkazů dle syntaxe jazyka SQL. Funkce onupdate se, jak již bylo řečeno, zavolá pouze při nové verzi databáze. Zde by mělo dojít ke smazání starých tabulek a vytvoření nových. Volitelně lze data zálohovat či překopírovat mezi databázemi. Velkou nevýhodou třídy SQLiteOpenHelper při použití bez komponenty Content Provider je nutnost korektně otevírat a uzavírat databázi po každém čtení. To se ukazuje jako komplikovaná záležitost při práci s více vlákny, která musí přistupovat do databáze. Proto se většinou SQLite databáze používají v rámci komponenty Content Provider jako úložiště dat. 2.7 Vlákna a asynchronní operace Systém Android nabízí standardní nástroje pro práci s více vlákny vycházející z implementované verze jazyka Java. V mobilní aplikaci se používá základní třída Thread nabízející nejjednodušší použití. Typicky provádí činnost ve své run () metodě a po skončení se ukončí. Díky implementaci grafického rozhraní nelze přímo přistupovat a měnit grafické objekty z jiných vláken než je vlákno aplikační. Pro tyto případy lze použít volání funkce runonuithread (), která interně přiřadí objekt typu Runnable do fronty událostí. Třída Runnable slouží pro spouštění jednoduchého kódu mezi vlákny. Dalším prvkem umožňujícím provádět blokující operace je třída AsyncTask, která, jak název napovídá, slouží pro vykonávaní asynchronních úloh v aplikaci. Její implementace umožňuje před startem (metoda onpreexecute () ) a po dokončení úlohy (metoda onpostexecute () ) přistupovat ke grafickým komponentům a měnit je. Další možností, kdy lze měnit grafická data, je metoda publishprogress (). Typicky se používá pro informování uživatele o pokroku dané činnosti, například stahování dat. Není proto nutné volat další funkce pro práci na hlavním vlákně aplikace. 38

39 KAPITOLA Společné vlastnosti aplikace pro mobily a tablety V prvotním vývoji byla pouze aplikace pro zařízení typu tablet, nicméně postupem času se ukázalo jako žádoucí vytvořit vhodnou aplikaci i pro mobilní zařízení. Velikosti a parametry mobilního telefonu neumožňují mít stejně efektní a vizuálně přitažlivou grafiku aplikace, proto bylo rozhodnuto vytvořit novou grafiku pro mobilní telefony, která bude lépe respektovat limity velikosti displeje a jejíž ovládání bude uzpůsobeno menšímu prostoru. Z tohoto důvodu došlo k určitému stupni rozdělení aplikační a grafické části aplikace. Všechny periodické operace běžící v samostatných vláknech jsou přenositelné mezi zařízeními, ale reakce na ně a změna grafických prvků je již závislá na konkrétní implementaci. Stejně tak je přenositelné rozdělení na několik modulů v rámci licencování aplikace. 3.2 Komunikační služba Služba ve třídě CommunicationService byla vytvořena za účelem generalizace a zjednodušení veškeré komunikace mezi aplikacemi a dalšími systémy. Ke službě se aktivity připojují pomocí metody bind, jsou tedy svázané se službou. Každá aktivita má tak referenci na běžící objekt služby a může volat její veřejné metody. Služba obsahuje kromě funkcí pro volání http metod a obsluhu komunikace se systémem imm také jednoduchou správu komunikačních vláken. Název třídy vlákna GetCamRecording GetClimmState GetEpsnet GetInfo GetPlaylist GetShuffleAndRepeat Funkce Získání informace o kamerách, které právě nahrávají Periodické dotazování serveru o stavu klimatizace Slouží pro komunikaci s centrálou CU2-01M, se kterou komunikuje ve smyčce každých cca 100ms. Používá se pro získání informace o tom co se děje v konkrétních zónách systému imm. Vyžádání seznamu přehrávaných filmů či hudby na dané zóně. Zasílá aplikaci informaci o stavu přehrávání ve vybrané zóně, zda je zapnutý režim náhodného přehrávání či režim opakování. Tabulka 9 Přehled komunikačních vláken 39

40 Komunikačním vláknem je myšleno vlákno, ve kterém běží procesy, které by jinak blokovaly hlavní chod aplikace. Typicky to jsou periodická volání na dotazování stavu nějaké hodnoty. Každé takové vlákno má jako jeden z parametrů konstruktoru rozhraní, přes které informuje aktivitu o výsledku činnosti. Základním vláknem, od kterého všechna ostatní dědí, je třída BasicThread. Tato třída implementuje funkce pro bezpečné spuštění a zastavení vláken [9] Komunikace se systémem inels Pro úspěšné navázání komunikace je nutné implementovat celý protokol EPSNET popsaný v kapitole a komunikovat s centrálou CU2-01M. Proto byl napsán samostatný klient v jazyce Java, který obstarává celou komunikaci mezi centrálou a aplikací. Tento klient byl součástí semestrální práce Projekt 1, nicméně od doby vzniku práce prošel postupným rozvojem a jeho nynější podoba je poměrně odlišná. Pro správný chod epsnet klienta je nutné mít stažený správně formátovaný soubor export.pub, který se ukládá do aplikační složky běžně nepřístupné. Při vytváření nové instance epsnet klienta se tedy načte tento soubor a vytvoří se v paměti struktura reflektující rozložení a adresy připojených epsnet prvků. Parametrem konstruktoru je IP adresa centrály CU2-01M. Obecnou funkcí pro odesílání jakékoliv zprávy je funkce SendAndReceive, která vytvoří EPSNET UDP paket, zašle ho a vrátí odpověď. Pokud se z nějakého důvodu nepodaří paket odeslat, vrátí chybovou hlášku. Důvodem chyby odeslání může být například nedostupnost hostitele nebo nemožnost zahájit komunikaci. Pro zapisování hodnot do PLC slouží obecná funkce WriteValue, která má za parametr zařízení, na které se zapisuje, a hodnotu, kterou je třeba zapsat. Na začátku prohledá objekt _exportpub, jenž v sobě má informace o uloženém souboru export.pub, a nalezne index, pod kterým k němu bude opětovně přistupovat. Dle zařízení se rozhodne, zda se jedná o prvek typu REAL (např. stmívače) nebo BOOL (spínače, světla, ), a použije se příslušná funkce, pro REAL je to Writen a pro BOOL Writeb. Funkce pro čtení stavů z nastavených zařízení jsou ReadAll,ReadSubset a ReadnAll. Jejich vzájemný stav popisuje nejlépe následující obrázek: 40

41 Zahájení čtení - nastavení čtených zařízení Funkce ReadAll Vrácení výsledku pro všechny zařízení Rozdělení zařízení po 310 (limit ESPNET paketu) Získání výsledků pro sadu zařízení Funkce ReadSubset Vytvoření ESPNET UDP paketu a jeho zaslání Funkce SendAndReceive Vytvoření ESPNET zprávy Funkce appendmessageforvars Rozdělení zařízení po 62 (limit ESPNET zprávy) Funkce ReadnAll Získání výsledku z centrály Obrázek 22 Orientační schéma hromadného čtení prvků z centrály CU2-01M Všechna činnost epsnet klienta běží v samostatném vlákně třídy GetEpsnet, která má veřejné metody pro odesílání dat do centrály. Při prvním startu tohoto vlákna se zavolají dvě konfigurační metody pro zahájení komunikace s centrálou CU2-01M, a to Ident a Connect popsané v předchozích kapitolách. Celá komunikace poté probíhá ve smyčce cyklu while, ve kterém se provede vyčtení stavu z centrály či případné odeslání nových dat a poté se vlákno uspí na 100 ms. Vyčtená data jsou před uspáním vlákna uložena do kolekce a dojde k jejich porovnání s předchozím stavem čtení. Tato optimalizace se ukázala jako nutná pro minimalizaci obnovy grafických komponent. Takto se obnovují jenom komponenty, u kterých došlo ke změně stavu. while (Thread.currentThread() == runner) { HashMap<String, String> result = new HashMap<String, String>(); if (should_send) { for (int i = 0; i < name.length; i++) m.writevalue(name[i], Float.valueOf(value[i])); should_send = false; } if (devices!= null) result = (HashMap<String, String>) m.readall(devices).clone(); listener.onespnetreceived(checkdifferences(resultold, result)); } sleep(100); Obrázek 23 Ukázka čtení dat z centrály CU2-01M ve vlákně Komunikace se systémem imm Jelikož je systém imm tvořen aplikací běžící na systému Linux, bylo nutné vyřešit způsob komunikace a předávání povelů z mobilního zařízení do systému imm. Nejsnazším a nejefektivnějším se ukázalo vytvořit v systému imm nějaký druh serveru, přes který by mobilní aplikace komunikovala a který by tak tvořil společný most. Možností implementace serveru bylo 41

42 velice mnoho, jelikož je však aplikační část systému imm napsána v jazyce Python, musela se vybrat taková, která umožňuje snadnou přenositelnost informací mezi platformami. Proto se zvolil protokol XML-RPC [11], který byl prvně představen společností Microsoft v roce 1998 a stál se základem pro nový formát SOAP. Rozhodujícím důvodem byla snadná implementace na obou platformách a existence kompaktních knihoven. Samotný XML-RPC slouží pro snadné volání vzdálených procedur. Jedná se pouze o systém pravidel a norem říkající jak formátovat posílaná data. Formát dat je ve tvaru XML, tudíž je velice přehledný a snadno čitelný, a data jsou přenášena pomocí http protokolu. Hlavní výhodou protokolu je jeho poměrná nenáročnost a srozumitelnost. Umožňuje vracet i návratové hodnoty jako výsledek volané funkce. Nabízí základní škálu datových typů, jako jsou pole, řetězce a číselné typy. Každé volání serverové funkce předchází xml tag <methodcall> následované názvem metody v xml tagu <methodname>. Odpověď potom přijde v tagu <methodresponse> následovaným jednotlivými proměnnými. Jako komunikační knihovna implementující protokol XML-RPC v systému Android bylo vybráno otevřené řešení, a to projekt android-xmlrpc [12] nabízející velmi paměťově nenáročnou implementaci protokolu. Pro správnou funkci knihovny je nutné korektně vytvořit novou instanci třídy XMLRPCClient a poté lze už volat jednotlivé funkce. Pokud se při komunikaci se serverem vyskytne chyba nebo server požadavek zamítne a vrátí chybový kód, knihovna vyvolá systémovou výjimku. XMLRPCClient client = new XMLRPCClient(Constants.Preffix+ipServer+Constants.Suffix); try { Boolean result = (Boolean) client.call("ping"); } catch (XMLRPCException e) { e.printstacktrace(); } Obrázek 24 Ukázka použití XML-RPC knihovny 3.3 Zahájení komunikace a stažení dat ze serveru Při prvním startu aplikace je uživatel vyzván, aby zadal IP adresu XML-RPC serveru. Toto je nezbytný krok, bez kterého nelze zahájit komunikaci. Po zadání IP adresy se pro kontrolu dostupnosti spojení se serverem při každém startu aplikace volá funkce Ping, která vrací pouze jednoduché logické hodnoty true/false dle stavu připojení. V případě, že se nepodaří se serverem spojit, dojde k opakovanému volání funkce Ping s periodou 5 sekund. Pokud se aplikaci podaří navázat spojení se serverem, dojde k vyžádání data poslední aktualizace konfigurace domu. Je-li datum uložené změny v zařízení starší nebo není-li vůbec přítomno, dojde k vyvolání nového stažení dat. Před samotným zahájením stahování se ukončí všechna běžící komunikační vlákna a odstraní se uložená data o konfiguraci domu, aby nedošlo ke vzniku 42

43 případných kolizí. Data jsou uložena pomocí komponenty Content Provider využívající SQL databázi. Stažení nových dat zabezpečuje třída DownloadData, která je implementuje asynchronní volání z třídy AsyncTask. Součástí konstruktoru této třídy je dialog, konkrétně třída ProgressDialog, která slouží pro informování uživatele o stavu stahování dat ze serveru. Instanci dialogu není vhodné vytvářet mimo kontext dané aktivity, a proto je nutné ji předávat v rámci konstruktoru. Druhou částí je rozhraní, přes které bude aktivita informována o ukončení činnosti asynchronní úlohy. V těle samotné úlohy se postupně volají funkce pro dotazování serveru. Jak bylo zmíněno v kapitole 1.4.1, při konfiguraci domu se vytvoří soubor rooms.xml, který definuje rozložení prvků v místnostech. Server implementovaný na straně imm potom s tímto souborem pracuje a na vyžádání zasílá informace o jednotlivých místnostech formou textového řetězce jako odpověď na volání funkce getroomdevices. Tato data je nutné korektně zpracovat a přeložit na systémové objekty, o což se stará funkce ReadDevices. Toto se ukázalo jako poměrně komplexní problém, neboť struktura dat není vždy stejná. Například informace o pořadí prvku v rámci grafického řazení nemusí být přítomna, proto je využito řetězení podmínek if ošetřující všechny varianty. Po stažení všech dat dojde k přiřazení typů a adres k epsnet prvkům ze souboru export.pub tak, aby se s ním dále již nemuselo pracovat, neboť práce se soubory je obecně pomalá. getcameras Získaní všech instalovaných kamer getcamerainfo Detail jednotlivé kamery getplayerslist Informace o všech zónach a jejich IP getroomdevices Detail jednotlivých místností getrooms Získání všech nastavených místností getclimms Získání všech instalovaných klimatizací getplcip IP adresa centrály CU2-01M getexportpub Definice hardwarových prvků ismieleplugged Informace zda jsou v domě Miele spotřebiče Obrázek 25 Postupné volání funkcí pro stažení dat 3.4 Uložení dat a přidružené datové struktury Pro snadnější a intuitivnější práci s daty byly vytvořeny třídy kopírující jednotlivé typy grafických prvků. Základním prvkem, od kterého všechny další dědí, je třída BaseDevice obsahující výčtový typ zařízení, identifikační číslo prvku v databázi a identifikační číslo místnosti. Další prvky jsou vypsány v následující tabulce: 43

44 Název třídy Typ objektu a jeho popis SceneDevice Představuje ikonu scény. Scénou je myšleno spínání více prvků najednou například vypnutí všech světel v místnosti. EpsnetDevice Obecné epsnet zařízení. Může to být například světlo, zářivka nebo odvlhčovač. V aplikaci je definováno jako obecný epsnet prvek, u kterého se rozlišuje, zda lze pouze spínat (typ BOOL ) nebo lze spojitě měnit jeho hodnotu (typ REAL ). ThermoDevice Zařízení typu teploměr. Může mít tři stavy obecný teploměr, teploměr venku a uvnitř. MeteoDevice Informace nutné pro vykreslení ikony meteostanice. Obsahuje sadu konstant pro úpravu hodnoty vyčtených z centrály. ShutterDevice Slouží pro kontrolu žaluzií. Žaluzie mají svůj speciální systém ovládání rozdílný od klasických epsnet zařízení, protože znám jejich polohu, jen pokud se pohybují. HeatDevice Reprezentace zařízení typu topení. U tohoto topení lze měnit jeho režim funkce, kterým se mění zároveň i požadovaná teplota. Interně má v sobě adresy všech režimů a zařízení braného jako teploměr, které se periodicky vyčítají. ClimmDevice Jsou-li v domě nainstalované nějaké klimatizační jednotky, vytvoří se tento objekt. Nese informaci o typu klimatizace, její jméno a grafickou reprezentaci. ShortcutDevice V aplikaci pro tablety lze zobrazit různé zástupce nainstalovaných aplikací, kteří se pak dají snadno spouštět. Právě tyto zástupce reprezentuje tento objekt. CameraDevice Objekt pro vizualizaci ovládání kamer. Může mít dvě ikony podle počtu nastavených kamer. ZoneDevice Pokud má místnost přiřazenu nějakou zónu, zobrazí se ikona pro rychlý vstup do obrazovky ovládání multimédií. Podle typu tohoto zařízení se pak nastaví typ a počet ikon. Tabulka 10 Seznam objektů pro grafickou reprezentaci 3.5 Licencování Při vývoji aplikace se ukázalo jako nezbytné ochránit aplikaci proti nepovolenému kopírování. Operační systém Android bohužel v tomto ohledu nenabízí mnoho efektivních možností bez nutnosti využívat služeb firmy Google. Nejschůdnějším řešením se ukázala online registrace aplikace proti webovému serveru. Tímto se zároveň otevřela cesta i pro vytvoření demo aplikace s omezenými funkcemi a časově omezenou dobou funkčnosti. Bez online registrace to nebylo 44

45 možné, neboť nebylo možné věrohodně ověřit datum platnosti aplikace. Uživatel si mohl například posunout datum v zařízení a tím obejít systém kontroly. Proto má každé zařízení speciální unikátní identifikátor, podle kterého lze poznat, zda k něčemu takovému již nedošlo. V rámci větší flexibility licencování byla aplikace rozdělena na jednotlivé moduly, které se dají volitelně zapnout či vypnout. Implementaci licencování řeší třída LicenceManager, jež se inicializuje při startu každé aktivity a hlídá povolené moduly. K výměně dat mezi webovou službou a aplikací byl zvolen formát JSON, který nabízí kompaktní a nízko objemový transfer dat [13]. Ve své podstatě se jedná o textový řetězec, do něhož jsou data zabalena. Umožňuje zasílat jak kolekce klíč/hodnota, tak pole hodnot. Jedná se o velice univerzální zápis hodnot, který je velice snadno přenositelný mezi více programovacími jazyky, čehož se v aplikaci využívá. Protokolem, přes který se data odesílají, je JSON-RPC [14]. Tento protokol je obdobou protokolu XML-RPC, jen místo formátu dat xml využívá json. Tím dosahuje mnohem menšího datového objemu. Obrázek 26 Ukázka licencování 45

46 KAPITOLA Aplikace pro tablety a referenční zařízení Jako grafická forma ovládání systému inels byla zvolena varianta ovládání pomocí tabletu s interním označením itp-t. Pod pojmem tablet si lze představit zařízení s relativně velkým displejem (největší mají zhruba 10 palců úhlopříčku), které je ještě schopen člověk pohodlně držet v obou rukách. Jejich výbavu většinou zahrnuje wifi síťová karta umožňující komunikaci mezi více zařízeními a tabletem. Volitelně lze nalézt modely s 3G modemem nebo klasickým GPRS. Zařízení dnes již de fakto supluje klasické notebooky a do budoucna se jejich role bude ještě zvyšovat. V tomto kontextu se také začíná mluvit o tzv. Post PC éře, předznamenávající útlum klasických stolních počítačů. V současné době však existuje nepřeberné množství zařízení splňujících podmínky pro označení tablet. Rozhodujícím faktorem u nich však je operační systém, ten stanovuje celkovou použitelnost zařízení, stejně jako možnosti rozšíření zařízení o přídavné periferie. Jako výchozí implementační systém byl zvolen systém Android, neboť v době vzniku práce byla zařízení s tímto operačním systémem cenově dostupnější a tudíž přístupnější pro běžného uživatele. Z historických důvodů byl také vybrán tablet Samsung Galaxy Tab jako referenční zařízení, protože při vytváření aplikace poskytoval jako jediný dostatečný výkon a odezvu. S postupem času a obrovským rozmachem tohoto typu zařízení se ukázalo nezbytným upravit aplikaci také na jiné druhy zařízení, zejména co se týče typu a velikosti displeje. Proto bylo zvoleno jako druhé referenční zařízení Samsung Galaxy Tab 10.1 s větší úhlopříčkou. Oba tablety mají rozdílnou verzi operačního systému Android, nicméně systém zaručuje zpětnou kompatibilitu a aplikace napsaná pro starší zařízení funguje bez potíží i na novějším tabletu. Z těchto důvodu byla zvolena jako výchozí verze operačního systému verze 2.2 Froyo. Obrázek 27 Zařízení Samsung Galaxy Tab [15] a Samsung Galaxy Tab 10.1 [16] 46

47 Samsung Galaxy Tab Samsung Galaxy Tab 10.1 Velikosti displeje 7 palců 10.1 palců Hustota displeje 170 ppi 149 ppi Rozlišení displeje 1024x600 px 1280x800 px Procesor 1 GHz Cortex A8 2 jádrový 1 GHz Cortex A9 Grafická karta PowerVR SGX540 ULP Geforce Velikost paměti RAM 512 MB 1 GB Verze operačního systému Android 2.2 Froyo Android 3.2 Honeycomb Tabulka 11 Přehled hlavních vlastností referenčních zařízení 4.2 Grafická implementace hlavní obrazovky Dá se říci, že každý modul aplikace má svoje grafické řešení, které běží v samostatné aktivitě. Grafické rozhraní je definováno pomocí xml souborů obsahující jednotlivé elementy. Hlavní obrazovku tvoří kontejner LinearLayout, kde se vykreslují jednotlivé ikony zastupující různá zařízení. V kontejneru jsou také umístěny fragmenty pro zobrazení času, nastavení hodnoty stmívání a informace o stavu v zónách. Aby se předešlo komplikacím s vytvářením rozdílných rozhraní dle velikosti a hustoty pixelů displeje, je šířka prvků určena poměrově. To zaručí přibližně stejný vzhled aplikace na jakémkoliv tabletu. Obrázek 28 Ukázka grafického rozhraní hlavní obrazovky tabletu Při startu aplikace a poté při každé změně místnosti dojde k načtení všech zařízení, která se mají vykreslit, jedná se například o epsnet prvky či zóny. Samozřejmě je nutné také zohlednit licenční nastavení aplikace a povolit či zakázat některá zařízení. Poté se zařízení rozdělí do 6 kategorií Funkce, Klima, Bezpečnost, Média, Oblíbené a Scény. Toto rozdělení je pouze informativního charakteru, neboť uživatel si může pomocí webových konfiguračních stránek 47