Č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
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
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.
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.
Obsah KAPITOLA 1 ........................................................................................................................... 9 1.1
Úvod ................................................................................................................................. 9
1.1.1 Shrnutí cílů práce .............................................................................................................. 9 1.2
Současné typy domovních instalací ................................................................................. 10
1.3
Systém iNELS ................................................................................................................. 11
1.3.1 Centrální jednotka CU2-01M .......................................................................................... 12 1.3.2 Komunikace v systému iNELS ........................................................................................ 12 1.3.3 Protokol EPSNET ........................................................................................................... 14 1.3.4 Komunikační prostředky protokolu EPSNET .................................................................. 15 1.3.5 Instalační soubor ............................................................................................................. 17 1.4
Multimediální systém iMM ............................................................................................. 17
1.4.1 Konfigurační rozhraní systému iMM ............................................................................... 18 1.4.2 Ovládání spotřebičů MIELE ............................................................................................ 19 1.5
Celkové zapojení systému ............................................................................................... 19
KAPITOLA 2 ......................................................................................................................... 20
2.
Operační systém Android ................................................................................................ 20
2.1
Verze operačního systému a napojený ekosystém ............................................................ 21
2.2
Architektura systému ....................................................................................................... 22
2.3
Struktura aplikací ............................................................................................................ 24
2.3.1 Charakteristika komponenty „Activity“ ........................................................................... 25 2.3.2 Charakteristika komponenty „Service“ ............................................................................ 28 2.3.3 Charakteristika komponenty „Broadcast Receiver“.......................................................... 29 2.3.4 Charakteristika komponenty „Content Provider“ ............................................................. 30 2.3.5 Vlastnosti objektu „Intent“ .............................................................................................. 31 2.3.6 Soubor „AndroidManifest.xml“ ....................................................................................... 31 2.3.7 Zdroje dat aplikace .......................................................................................................... 33 2.4
Grafický systém .............................................................................................................. 34
2.4.1 Grafická komponenta „ListView“.................................................................................... 36 2.4.2 Menu systém ................................................................................................................... 36 2.5
Vstupní uživatelské události ............................................................................................ 37
2.6
Úložiště dat ..................................................................................................................... 37
2.7
Vlákna a asynchronní operace ......................................................................................... 38
KAPITOLA 3 ......................................................................................................................... 39 3.1
Společné vlastnosti aplikace pro mobily a tablety ............................................................ 39
3.2
Komunikační služba ........................................................................................................ 39
3.2.1 Komunikace se systémem iNELS .................................................................................... 40 3.2.2 Komunikace se systémem iMM ....................................................................................... 41 3.3
Zahájení komunikace a stažení dat ze serveru .................................................................. 42
3.4
Uložení dat a přidružené datové struktury........................................................................ 43
3.5
Licencování..................................................................................................................... 44
KAPITOLA 4 ......................................................................................................................... 46
4.1
Aplikace pro tablety a referenční zařízení ........................................................................ 46
4.2
Grafická implementace hlavní obrazovky ........................................................................ 47
4.2.1 Ikona meteostanice .......................................................................................................... 48 4.2.2 Popis fragmentů .............................................................................................................. 48 4.2.3 Klimatizace ..................................................................................................................... 50 4.3
Ovládání multimédií ........................................................................................................ 51
4.3.1 Prohlížení fotografií ........................................................................................................ 53 4.4
Spotřebiče Miele ............................................................................................................. 53
4.5
Bezpečnostní kamery ...................................................................................................... 53
4.5.1 MJPEG ........................................................................................................................... 54 4.5.2 Zobrazení dat z kamery ................................................................................................... 54 4.5.3 Nahrávání obrazu z kamery ............................................................................................. 55 KAPITOLA 5 ......................................................................................................................... 56 5.1
Aplikace pro mobilní telefony ......................................................................................... 56
5.2
Grafická implementace hlavní obrazovky ........................................................................ 56
5.2.1 Animace komponent ....................................................................................................... 57 5.3
Ovládání prvků ................................................................................................................ 58
5.3.1 Ovládání spotřebičů s pomocí náklonu zařízení ............................................................... 59 5.4
Další rozvoj..................................................................................................................... 60
Závěr ....................................................................................................................................... 62 Seznam literatury ................................................................................................................... 63 Seznam obrázků ..................................................................................................................... 65 Seznam tabulek....................................................................................................................... 67 Seznam zkratek ...................................................................................................................... 68 Obsah CD ............................................................................................................................... 69
KAPITOLA 1 1.1 Ú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.
1.1.1 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
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. Řídící jednotka vytápění
Meteo senzor
Reléový výstup
Senzor teploty
Obrázek 1 - Centralizovaná systémy
10
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í
Senzor teploty
Meteo senzor
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
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.
1.3.1 Centrální jednotka CU2-01M Implementaci sběrnice CIB v systému iNELS zajišťuje centrální jednotka s označením CU201M. 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 61682. 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.
1.3.2 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
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.
0-1
2
MESI
PN
3
R
4-5
6-x
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
Určuje délku následujících dat. Dle konvence obsahuje bajt 4 vyšší část délky a bajt 5 nižší.
EPSNET 1-5
6 a dále
Samostatné zprávy sestavené dle EPSNET protokolu.
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).
Tabulka 1 - Popis polí v ESPNET UDP paketu 13
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
Použité zkratky mají následující význam: Zkratka SD1 SD2 SD4 LE LER SD2R DA SA FC DATA FCS ED SAC
Význam Úvodní znak 1 Úvodní znak 2 Úvodní znak 4 Délka dat Opakovaná délka dat Opakovaný úvodní znak 2 Cílová adresa Zdrojová adresa Řídící bajt rámce Vlastní data zprávy Kontrolní součet zprávy Koncový znak Krátké potvrzení Tabulka 2 - Význam použitých zkratek
1.3.4 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
Datové pole vypadá takto: Označení Význam LIS Délka identifikačního řetězce LIP Délka typu implementace protokolu LST Délka řetězce určujícího verzi struktur LSW Délka řetězce určujícího verzi softwaru Identifikační řetězec centrální jednotky Znak implementace protokolu Řetězec verze struktur Řetězec verze softwaru Tabulka 3 - Popis datového pole funkce ident
Bajt 0 1 2 3 4 4+LIS 4+LIS+LIP 4+LIS+LIP+LST
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
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 17112 UDINT PUB_INOUT system_Showroom_ALARM R B 17168 .0 BOOL PUB_INOUT system_Showroom_LOCKED R B 17168 .1 BOOL PUB_INOUT system_Showroom_LOCKING R B 17168 .2 BOOL PUB_INOUT system_AG2_ALARM R B 17288 .0 BOOL PUB_INOUT system_AG2_LOCKED R B 17288 .1 BOOL PUB_INOUT system_AG2_LOCKING R B 17288 .2 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í emailů. 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/RS485.
17
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
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 Topení
CU2-01M
Žaluzie
Klimatizace
Mobilní zařízení
Obrázek 11 – Ilustrační zapojení všech prvků do funkčního celku
19
Televize
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
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
Označení/Číslo
Datum vydání
Cupcake/1.5
Květen 2009
Donut/1.6
Říjen 2009
Eclair/2.0 – 2.1.x
Prosinec 2009
Froyo/2.2.x
Květen 2010
Gingerbread/2.3.x
Prosinec 2010
Honeycomb/3.x
Únor 2011
Ice Cream Sandwich/4.0
Říjen 2011
Popis změn První veřejná verze systému, přinesla nové grafické prvky stejně jako nové element HorizontalScrollView Přidána podpora pro VPN sítě, Nové linuxové jádro, Nový systém pro detekci dotykových gest Přepracováno API pro správu aplikačních služeb, Úprava událostí pro odchytávání stisku kláves Možnost instalovat aplikace na paměťovou kartu, Vytváření aplikací s administrátorskými právy Úprava grafického rozhraní, přidána podpora NFC a SIP komunikace, vylepšeno NDK Verze určená pro tablety, přidány nové objekty typu fragment, přidána nová notifikační lišta – „Action Bar“ Sjednocení telefonní a tabletí verze systému, představeno 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 emailovým účtem, kdy uživatel má k emailu 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
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
Správci obsahu
Systém pro vykreslení komponent
Aplikační rámec Správce activit
Správce oken
Správce balíčků
Správa polohy zařízení
Telefonní správce
Správa zdrojů
Prostředí OS Android
Knihovny Správce vykreslování
Notifikační správce
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
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 ()“.
Spuštění aplikace
Výzva ke spuštění Aplikace 1
Přijatá data
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
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.
2.3.1 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
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
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
Fragment byl odebrán nebo uživatel vyvola událost zpět onActivityCreated
onStart
onResume
Chod fragmentu
onPause
onStop
onDestroyView
onCreateView Fragment se vrátil ze zásobníku na obrazovku onCreate
;
onDestroy
onAttach
onDetach
Přidání fragmentu
Odebrání fragmentu
Obrázek 17 – Ukázka životního cyklu fragmentu
2.3.2 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
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
2.3.3 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
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.
2.3.4 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
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 emailech. 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.
2.3.5 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“.
2.3.6 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
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
Obraz v xml souboru
„Activity“
„Service“
<service>
„Broadcast Receiver“
„Content Provider“
<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. <provider android:name="com.itp.Database.DatabaseProvider" android:authorities="com.itp.databaseprovider" />
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é 32
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.
2.3.7 Zdroje dat aplikace Název
Vlastnosti
složky/idenfikátoru animator
anim
color
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ž
drawable
zmiňované bitmapové obrázky nebo o vytvořené grafické objekty pomocí definice v xml souborech.
layout menu
values
xml
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
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)
2–3
110 dpi
Normální (normal)
3-4
240 dpi
Velké (large)
4-7
180 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
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 „http://schemas.android.com/apk/res/android“, 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.
Obrázek 21 – Ukázka použité xml souboru s definicí elementů
35
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.
2.4.1 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í.
2.4.2 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
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
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
KAPITOLA 3 3.1
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
Funkce
GetCamRecording
Získání informace o kamerách, které právě nahrávají
GetClimmState
Periodické dotazování serveru o stavu klimatizace
GetEpsnet
Slouží pro komunikaci s centrálou CU2-01M, se kterou komunikuje ve smyčce každých cca 100ms.
GetInfo
Používá se pro získání informace o tom co se děje v konkrétních zónách systému iMM.
GetPlaylist
Vyžádání seznamu přehrávaných filmů či hudby na dané zóně.
GetShuffleAndRepeat
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
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].
3.2.1 Komunikace se systémem iNELS Pro úspěšné navázání komunikace je nutné implementovat celý protokol EPSNET popsaný v kapitole 1.3.3 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
Zahájení čtení - nastavení čtených zařízení Získání výsledků pro sadu zařízení Funkce ReadAll
Rozdělení zařízení po 310 (limit ESPNET paketu) Funkce ReadSubset
Vrácení výsledku pro všechny zařízení
Vytvoření ESPNET UDP paketu a jeho zaslání
Vytvoření ESPNET zprávy
Rozdělení zařízení po 62 (limit ESPNET zprávy)
Funkce SendAndReceive
Funkce appendMessageForVars
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ě
3.2.2 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
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
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
getCameraInfo
getPlayersList
Získaní všech instalovaných kamer
Detail jednotlivé kamery
Informace o všech zónach a jejich IP
getRoomDevices
getRooms
getClimms
Detail jednotlivých místností
Získání všech nastavených místností
Získání všech instalovaných klimatizací
getPlcIP
getExportPub
IP adresa centrály CU2-01M
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
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
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
KAPITOLA 4 4.1
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
Samsung Galaxy Tab
Samsung Galaxy Tab 10.1
Velikosti displeje
7 palců
10.1 palců
Hustota displeje
170 ppi
149 ppi
1024x600 px
1280x800 px
1 GHz Cortex A8
2 jádrový 1 GHz Cortex A9
PowerVR SGX540
ULP Geforce
512 MB
1 GB
Android 2.2 „Froyo“
Android 3.2 „Honeycomb“
Rozlišení displeje Procesor Grafická karta Velikost paměti RAM Verze operačního systému
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
kategorii změnit. Kontejnerem obsahujícím zařízení pro každou kategorii je poté třída „HorizontalScrollView“ reprezentující horizontální posun mezi ikonami. Veškerou práci s ikonami zařízení má na starosti třída „GraphicManager“, která obsahuje sadu statických metod spravujících přidávání a obnovu ikon. Při přidávání nové ikony se k její grafické reprezentaci přiřadí rozhraní pro příjem dotykových událostí. Poté se rozliší, o jaký typ ikony se jedná, a nastaví se korektní grafika dle zadání. Obdobně se postupuje při přijetí nové sady hodnot, která se zpracuje a dle typu zařízení se volá příslušná funkce.
4.2.1 Ikona meteostanice Zajímavou výzvou se ukázalo vyřešení ikony meteostanice. Dle grafického zadání se jedná o oblouk, v jehož středu se vykresluje název, naměřená hodnota a její jednotka. Ve spodní části při okrajích se pak zobrazují minimální a maximální hodnota. Bohužel nelze použít žádnou předem vytvořenou komponentu v systému Android, a proto byla vytvořena kompletně vlastní. Toho bylo docíleno pomocí implementace metody „onDraw()“, ve které se vykreslí část oblouku podle nastaveného úhlu začátku a konce. Dále se vykreslí druhý oblouk s rozdílnou šířkou a přepočítanou procentuální hodnotou na konečný úhel tak, aby bylo dosaženo zadaného grafického rozhraní. Toto implementuje třída „Arc“. Vykreslení textových polí je realizováno pomocí jednoduchých systémových komponent „TextView“. Celá grafika ikony je pak definována v samostatném xml souboru.
Obrázek 29 – Ukázka grafiky ikony meteostanice
4.2.2 Popis fragmentů Fragment pro zobrazení času obsahuje obsluhu vlastní grafické komponenty třídy „ScheduledTime“. Tato třída je potomkem komponenty „RelativeLayout“ a obsahuje jednoduché elementy „TextView“ pro zobrazení času. Korektní vypsání času vyžaduje jeho periodické zjišťování ze systému. Pro periodické volání je použit objekt „Handler“, který slouží pro opakované zasílání požadavků a jejich provádění. Již zmiňovanou výhodnou vlastností fragmentu je informace o stavu aktivity, ve které běží. Proto se ve fragmentu v metodách „onResume“ a „onPause“ spouští a vypíná periodické natavení času. Pokud by se toto nedělo a k zastavení obnovy času by nedošlo, bylo by to považováno za paměťový únik a postupem času by paměť došla. 48
Informace o stavu přehrávaných multimédií se na hlavní obrazovce vykreslují pomocí fragmentu třídy „FragPlayer“. Tento fragment obsahuje grafickou komponentu „LinearLayout“, do které se vkládají jednotlivé reprezentace zón. V grafickém detailu zóny se zobrazuje její název, stav přehrávání a případně časový postup, například při přehrávání hudební skladby. Pokud uživatel vyvolá událost dlouhého stisku na vybrané zóně, zobrazí se možnost rychlého ovládání formou tlačítek pro spuštění a zastavení přehrávání. Událost kliknutí potom vyvolá spuštění nové aktivity s detailem zóny, kde se jako parametr pro spouštění vkládá vybrané zařízení ve formě třídy „ZoneDevice“. Fragment také řeší celou obsluhu komunikace nutnou pro vyčítání dat. Obsahuje rozhraní, přes které dostává data od komunikačního vlákna. Toto vlákno je spouštěno a zastavováno opět v rámci životního cyklu fragmentu svázaného s aktivitou. Pro ovládání zařízení ze systému iNELS, která jsou typu „REAL“, například světla nebo lampy, bylo nutné umožnit uživateli nějakým způsobem plynule měnit jejich hodnotu. Jediný vhodný prostor pro vykreslení nějakého dostatečně velkého grafického prvku se nacházel při levém okraji aplikace, nicméně zde je už umístěno orientační rozdělení řádků na jednotlivé typy. Z tohoto důvodu fragment s nastavením hodnoty zařízení překrývá grafický element s rozdělením řádků a při svém zneplatnění se nastaví jako neviditelný. Samotný fragment tvoří programově vytvořený element třídy „VerticalProgressBar“, který ve své vykreslovací metodě „onDraw“ postupně zobrazuje tři obdélníky. Každý obdélník má jinak nastavenou tloušťku a barvu tak, aby bylo dosaženo kýžené grafické podoby. 1. obdélník
3. obdélník
2. obdélník
Obrázek 30 – Ukázka řešení nastavení hodnoty prvků „REAL“ Pokud se uživatel dotkne displeje kdekoliv v oblasti fragmentu, přepočítá se souřadnice z osy y na procentuální výšku celého fragmentu a je ihned odeslána do centrály CU2-01M, takže 49
uživatel vidí okamžitou změnu v zařízení. Pro automatické zneviditelnění komponenty byl implementován časový odpočet pomocí třídy „Handler“, konkrétně metody „postDelayed ()“. Tato metoda vykoná nějakou část kódu po uplynutí nastavené doby, zde je nastaveno 3000 ms. Po této době se fragment sám schová. Další možnost, kdy se fragment schová, je při ukončení dotykového gesta, kde se speciálně odchytává zvednutí prstu pomocí přiřazeného rozhraní.
4.2.3 Klimatizace Modul klimatizace byl do aplikace přidán v pozdější fázi vývoje, a proto obsahuje částečně atypická řešení. Systém iMM s klimatizací komunikuje přes převodník Ethernet/RS485, protože vybraný typ klimatizace nic jiného neumožňuje. Zatím jediným podporovaným zařízením je klimatizace od firmy LG PI485, jejíž API bylo zpřístupněno. Bohužel vybraný převodník není schopen operovat s více připojeními najednou, a proto s ním nelze komunikovat přímo z tabletu. Proto se v aplikaci ke klimatizaci přistupuje pomocí XML-RPC serveru a metod k tomu určených. Jak již bylo zmíněno v předchozích kapitolách, ikona klimatizace může mít čtyři stavy své formy, protože možností, jež lze nastavit, je poměrně hodně. Lze například měnit požadovanou teplotu, režim klimatizace (chlazení nebo vytápění) nebo rychlost otáček ventilátoru a další parametry. Název stavu
Popis
Menu
Zobrazuje dialog se všemi moduly zapnutými.
Mode
Temp
Slouží pro rychlé nastavení módu klimatizace. Módem klimatizace může být chlazení, odvlhčování, ventilace, topení nebo automatika. V tomto režimu lze v dialogu nastavit pouze požadovanou teplotu v místnosti s klimatizací. Dialog je v režimu atributy klimatizace. V tomto režimu je možné nastavit pouze
Attrs
dodatečné informace jako rychlost otáčení ventilátoru, naklonění lamel či uzamčení klimatizace. Tabulka 12 – Stavy klimatizace Každý stav pak po dlouhém stisku spouští jinou grafickou podobu třídy „KlimmDialog“.
Jedná se o dialog, který se zobrazí nad aplikací. Tento dialog přijímá informace z komunikačních vláken a zobrazuje tak aktuální stav klimatizace. Ze serveru vždy přijde mapa hodnot všech parametrů a ty se pomocí rozhraní předají aplikaci. O obnovu stavu dialogu a ikon se pak stará třída „GraphicManager“ pomocí statických metod. Ikony zobrazení klimatizace lze také ovládat jednoduchým kliknutím, kterým by se měla klimatizace zapnout či vypnout.
50
Obrázek 31 – Dialog klimatizace se zobrazenými všemi moduly
4.3
Ovládání multimédií
Propojení se systémem iMM má svoje samostatné grafické řešení, do kterého se uživatel dostane kliknutím na příslušnou ikonu zóny. Celá koncepce zón je pak vlastně napojení na systém iMM. Pokud je k místnosti přiřazena nějaká zóna, zobrazí se ikona nebo ikony na displeji. Zde se rozlišuje, jestli se jedná pouze o audio zónu nebo o video zónu. V prvním případě se zobrazí pouze ikona, jejímž kliknutím se lze dostat do obrazovky ovládání přehrávání audia. Ve druhém se zobrazí čtyři ikony, každá pro vlastní modul multimédií. Těmito moduly je myšleno již zmíněné přehrávání audia, dále pak přehrávání videa, televizního programu a prohlížení fotografií. Všechny moduly mají v zásadě společnou grafiku, liší se jen zobrazované seznamy a tlačítka
pro
kontrolu
stavu
zóny.
Výchozí
aktivitou
pro
všechna
multimedia
je
„MultimediaActivity“, od které moduly dědí veřejné metody. Každý modul má svoji aktivitu, ve které provádí činnosti nutné jen pro úpravy grafiky. Z tohoto důvodu došlo ke značnému zjednodušení programu a kód aplikace je také čitelnější. Ve vrchní části se zobrazuje název právě vybrané zóny. Klikne-li se na tento název, zobrazí se dialog pro výběr dalších zón. Tyto zóny jsou filtrovány dle právě vybrané místnosti. Zóny se načítají z databáze a zde také dochází k jejich filtrování pomocí vhodně formulovaného SQL dotazu. Pod názvem zóny se zobrazuje informace o právě přehrávaném médiu v zóně, která se získává z komunikačního vlákna ve formě textového řetězce. V pravé části obrazovky jsou pak umístěna tlačítka pro změny stavu zóny. Nabízejí typické ovládání jako zastavení, spuštění, pozastavení nebo rychlý posun. Tyto tlačítka se nastavují dynamicky dle spuštěného modulu. 51
Kliknutí na každé tlačítko vyvolá spuštění asynchronní úlohy volající příslušnou funkci na serveru. V levé části se pak zobrazuje seznam souborů uložených na serveru, které slouží jako zdroj dat pro přehrávání. Jedná se tedy o jakýsi jednoduchý prohlížeč souborového systému. Seznam je realizován formou komponenty „ListView“ a má tedy svůj příslušný adapter pro zobrazení dat ve třídě „FileAdapter“. Zde se data filtrují dle příslušného modulu, například pro hudbu jen soubory s hudební koncovkou a analogicky pro další. Adaptér rozlišuje typ souboru a zobrazuje vhodnou ikonu. Každý modul má jinou výchozí adresu v souborovém systému na disku. Tato adresa se zašle na server a ten vrací všechny soubory na dané adrese ve formě textového řetězce. Při kliknutí na nějaký prvek seznamu se zhodnotí, jestli se jedná o složku nebo soubor. Je-li to složka, pokračuje se v listování. V druhém případě se název souboru zašle na server a buď se spustí přehrávání, nebo se přiřadí do seznamu skladeb. Toto je závislé na právě vybraném modulu.
Obrázek 32 – Obecná kostra grafiky multimédií Seznam skladeb je realizován také pomocí komponenty „ListView“, jejíž obsah se pravidelně načítá ze serveru přes komunikační vlákno „GetPlaylist“. Jediným případem, kdy se nezobrazuje seznam skladeb, ale pouze detail pořadu, je modul televize, proto se zde ani komunikační vlákno nespouští. Právě přehrávaný soubor se v seznamu označí červenou barvou. Pro snadnou kontrolu přehrávání lze mazat soubory ze seznamu dlouhým stisknutím vybraného souboru. Aktivita pro přehrávání audio souborů má potom ve spodní části seznamu ještě tlačítka 52
pro smazání celého seznamu a náhodné nebo opakované přehrávání. U posledních dvou jmenovaných je nutné získávat informaci o jejich stavu ze serveru, protože by je mohl spustit někdo mimo aplikaci.
4.3.1 Prohlížení fotografií Je-li uživatel v modulu fotografií, může si vybranou fotografii zobrazit na zařízení. Při implementaci této možnosti se ukázalo jako komplikované zobrazovat jakoukoliv fotografii, neboť ty můžou mít značnou velikost a nemuselo by dojít k jejímu korektnímu načtení do paměti. Proto se fotografie na straně XML-RPC serveru ořízne na požadovanou velikost displeje a poté se pošle zpět aplikaci ve formě pole bajtů. K tomu slouží funkce „getPhoto“, která má jako parametry šířku a výšku displeje v obrazových bodech a dále adresu fotografie. Po přijetí fotografie se spustí nová aktivita, která ji zobrazí. Jedná se o aktivitu „FullImageActivity“ implementující sadu rozhraní pro detekci dotykových gest a obsahující třídu „Zoom“. Komponenta „Zoom“ dědí od třídy „ImageView“, jedná se tedy o vlastní řešení grafického elementu pro zobrazení obrázku. Důvodem vlastního řešení je možnost provádět úpravy obrázku dle dotykových gest uživatele. Takovým gestem může být například přiblížení nebo oddálení za použití pohybu dvou prstů směrem k sobě respektive od sebe. Dalším častým typem gesta může být posun obrázku při jeho přiblížení. Transformace obrázku je řešena pomocí transformační matice, jež se přepočítává podle zjištěných hodnot z dotykového gesta.
4.4
Spotřebiče Miele
Pokud je dům vybaven spotřebiči od firmy Miele, zobrazí se ikonka pro vstup do modulu Miele. V tomto modulu je zobrazen seznam dostupných zařízení v komponentě „ListView“ a po kliknutí na položku seznamu se zobrazí detail vybraného prvku. Zde se vypisuje jeho aktuální stav a další dodatečné informace, například u pračky v jaké je fázi praní. Úvodní stažení dat probíhá v samostatném vlákně třídy „GetMiele“, které při prvním startu stáhne seznam zařízení. Pokud se seznam nepovede stáhnout, nastala někde chyba v komunikaci a vlákno se o to pokusí za 10 sekund znovu. V případě úspěšného stažení dat dojde k načtení stavů a jejich zaslání aktivitě pomocí přiřazeného rozhraní. To se opakuje každých 100 ms.
4.5
Bezpečnostní kamery
Některé části této kapitoly jsou převzaty ze semestrální práce „Projekt 2“[17] věnující se implementaci bezpečnostních kamer. Nicméně od té doby prošel systém kamer částečným vývojem, proto určité části nejsou již platné. Přenos obrazu z moderních digitálních kamer lze rozdělit na dva problémy. Nejprve je potřeba obraz zakódovat do nějakého multimediálního formátu, a poté tento obraz poslat vhodným způsobem do koncového zařízení. Většina kamer 53
disponuje třemi video formáty – MJPEG, MPEG-4 a H264. Nejčastějším způsobem přenosu videa jsou protokoly HTTP a RTSP. Systém Android pak obsahuje podporu pro přehrávání formátu MPEG-4 a H264. Výsledkem již zmíněné semestrální práce bylo použití video formátu MJPEG a přenosu pomocí http protokolu, neboť se ukázal jako jediný široce použitelný a kompatibilní s většinou kamer.
4.5.1 MJPEG Zkratka pochází z anglického „motion joint photographics experts group“. Tento formát videa patří k nejčastější formě kódování obrazu v digitální technice. Každý snímek se komprimuje pomocí standardu JPEG, který využívá ke komprimaci obrazu metodu diskrétní kosinové transformace. Jedná se o ztrátovou kompresi, jež se projeví na výsledné kvalitě obrazu. Tento formát nedosahuje tak dobrého kompresního poměru jako jiné modernější formáty, což na druhé straně klade mnohem menší požadavky na výkon zařízení. Výsledkem je velké rozšíření tohoto způsobu kódování videa. MJPEG samotný nemá oficiální standard a z jeho absence vyplývají možné problémy vzájemné nekompatibility implementace formátu. Klíčové snímky jsou v tomto formátu všechny, a proto je vhodný např. pro rychlý posun ve videu.
4.5.2 Zobrazení dat z kamery Výsledný obraz z kamer se zobrazuje ve třídě „CameraPlayer“. Při spuštění si třída detekuje přijatá identifikační čísla kamer a podle jejich počtu sama pozná, zda se jedná o režim jedné, či více kamer. Poté si pro patřičná identifikační čísla kamer stáhne data z interní databáze. Data jsou ve formě objektů „Camera“ a obsahují informace o adrese videa a odkazy pro ovládání pohybu kamery. Poté inicializuje třídu „MjpegView“ zavoláním metody „setDataSource“. Je zde implementováno ovládání kamer přes výsuvný panel s menu a ovládání kamer pomocí dotykových gest. Pro rozpoznání dotykového gesta kliknutí je použita třída GestureDetector, která zobrazuje menu pro ovládání kamer.
54
Obrázek 33 – Ukázka grafického rozhraní ovládání kamer
4.5.3 Nahrávání obrazu z kamery Samotná nahrávaná data jsou samozřejmě ukládána na klientský server, protože preferovaná mobilní zařízení by neměla dostatečný úložný prostor a hlavně nejsou stále připojena do systému iMM nebo vůbec zapnuta. Proto byla vytvořena speciální funkce na straně serveru camRec, která umožňuje spustit nahrávání zadané kamery. Jako parametr této funkce je url adresa nahrávaného videa a název souboru pro nahrávání. Zde se ovšem nejedná o adresu mjpeg videa, ale o adresu s videem v lepší kvalitě, např. formátu H.264 nebo MPEG-4. Uživatel si může v nastavení vybrat, pod jakým názvem se bude obraz ukládat, a po stisku tlačítka se zavolá již zmíněná funkce na serveru a začne se nahrávat. Pro zjištění, zda daná kamera již nějaký obraz nahrává, slouží funkce camGetRecStreams, kterou je nutno periodicky volat. Toto volání je realizováno vlastním vláknem, které vrací hodnoty zpět do aplikace přes přidělené rozhraní.
55
KAPITOLA 5 5.1
Aplikace pro mobilní telefony
Tato aplikace je stále předmětem intenzivního vývoje a není na stejné úrovni implementace systému iMM jako verze pro tablety „iTP-T“. Systém iNELS je však téměř zcela zapracován a nové grafické provedení přináší v jeho ovládání větší uživatelský komfort. Hlavním rozdílem je použité zobrazení v režimu portrét na rozdíl od krajiny pro tablety. To vychází zejména z lepší uživatelské zkušenosti při použití s mobilním telefonem. Jako referenční mobilní telefon byl zvolen model „Samsung Galaxy S2“ nabízející více než dostatečný výkon a rezervy v operační paměti. Z důvodů největší rozšířenosti verze operačního systému Android 2.2 „Froyo“, jak ukazuje Obrázek 12, byla tato zvolena jako výchozí pro vývoj aplikace. Mobilní telefon bude komunikovat se systémy iMM a iNELS pomocí wifi síťové karty. Do budoucna se počítá i s rozvojem vzdáleného ovládání domu přes internet, kde lze využít 3G nebo klasické GPRS připojení. Mobilní aplikace je kompatibilní se všemi mobilními telefony, jejichž velikost displeje je větší nebo rovna kategorii „normal“, tedy zhruba 3 a více palců úhlopříčky. Pro menší displeje není a ani nebude aplikace optimalizovaná, neboť na takto malých zařízeních by uživatelská zkušenost byla nedostačující. Grafické elementy by nešly správně ovládat a mohly by vznikat různé grafické artefakty.
Velikosti displeje
4.3 palce
Hustota displeje
217 ppi
Rozlišení displeje
800x480 px 2 jádrový 1.2 GHz Cortex A9
Procesor Grafická karta
Mali 400MP
Velikost paměti RAM Verze operačního systému
1 GB Android 2.3.3 „GingerBread“
Tabulka 13 – Vlastnosti referenčního telefonu Samsung Galaxy S2 spolu s jeho obrázkem[18]
5.2
Grafická implementace hlavní obrazovky
V horní části aplikace se zobrazuje v komponentě „ViewPager“ aktuální vybraná místnost. Tato komponenta řeší automatickou výměnu svého obsahu v závislosti na uživatelské události. Pokud uživatel provede dotyk zleva doprava, adekvátně se tím změní data v komponentě. Pro takové chování bylo nutné vytvořit speciální adaptér, který bude správně reagovat na změnu stavu. Tímto adapterém je třída „RoomAdapter“ implementující metodu „instantiateItem“, ve které 56
vytváří novou komponentu „TextView“ pro zobrazení jednoduchého textu jako název místnosti. Informace o stavu zvolených zón jsou pak zobrazeny v samostatném fragmentu třídy „FragPlayer“, která obsluhuje grafickou komponentu „ViewFlipper“. Tato komponenta slouží pro přepínání mezi více grafickými prvky, a tak usnadňuje vytvoření animačního přechodu mezi nimi. Je to potomek třídy „FrameLayout“, tudíž je preferováno, aby v ní byl zobrazen jen jeden prvek. Zmíněný fragment obstarává komunikaci s XML-RPC serverem přes příjem události z vlákna „GetInfo“, které ji zpracovává a adekvátně přizpůsobuje komponentu „ViewFlipper“. Poslední část obrazovky tvoří element „ListView“. V něm se zobrazují všechny ovládané prvky v grafické formě dlaždic. Tyto dlaždice pak prochází celou aplikací a jsou sjednocujícím grafickým prvkem. Vytvoření a správa dlaždic je poměrně komplikovaný proces. Nejprve se musí vytvořit seznam všech zařízení, která se mají zobrazit na displeji. Poté se musí k těmto zařízením přidat typ dlaždice. Mohou být dva typy dlaždice – poloviční a plný, který je vykreslen na celou šířku telefonu. Ve své podstatě je programově i poloviční typ dlaždice vykreslen přes celou šířku, ale při vytváření grafiky se použije jiný soubor a dojde k rozpůlení. Po přidání zařízení se vytvoří nová instance třídy „DeviceAdapter“, která již řeší samotné vykreslování a která se přiřadí komponentě „ListView“. Třída „DeviceAdapter“ je adaptérem, přes který „ListView“ zjišťuje, jak a které elementy má zrovna vykreslit. Z důvodu recyklace grafických prvků musí mít každá kombinace dlaždic svůj unikátní identifikátor, aby nedošlo k mylnému použití nevhodné grafiky.
Obrázek 34 – Ukázka grafického rozhraní hlavní obrazovky mobilního telefonu
5.2.1 Animace komponent V systému Android je implementován poměrně robustní způsob animování komponent. V podstatě stačí vytvořit dle pravidel xml soubor, který se poté použije ve třídě „Animation“. Tato 57
třída řeší veškerou transformaci a pohyb grafického elementu. Elementárními animacemi jsou změna průhlednosti, měřítka, posunutí a rotace. Všechny tyto prvky se dají libovolně řetězit a každý se může provádět libovolně dlouho. Důležitým prvkem pro každou animaci je tzv. „interpolar“. Ten definuje míru změn během provádění animace. Například může jít o opakování nebo o zrychlení či zpomalení animace. První použitou animací je změna ve fragmentu „FragPlayer“. Použitá komponenta „ViewFlipper“ nabízí snadnou implementaci vstup a výstupu grafického prvku. Pomocí xml souboru byl definován výstup současného názvu zóny ze středu k levému okraji za použití animační primitivy posunu. Obdobně je řešen vstup nové zóny. <set xmlns:android="http://schemas.android.com/apk/res/android" android:interpolator="@android:anim/accelerate_decelerate_interpolator" >
Obrázek 35 – Ukázka xml souboru s animací Další animace se týkají samotných dlaždic. Po kliknutí na dlaždici, jejíž stav lze měnit, se provede rotace dlaždice kolem své osy. K tomu je využita třída „Rotation3D“ vytvořená společností Google. Ta sama počítá transformaci elementu dle zadaného počátečního a konečného úhlu rotace. Pokud dlaždici nelze ovládat, tudíž je jen pro čtení, provede se druhá animace reprezentující neovladatelnost prvku. Jedná se o opakovanou animaci posunu dlaždice o definovanou hodnotu. Je zde použit tzv. „CycleInterpolar“, který zaručuje počet opakování dle stanovené hodnoty.
5.3
Ovládání prvků Nečekaným problémem se ukázalo odchytávání uživatelských dotyků na vybranou
poloviční dlaždici. Jelikož programově jsou tyto dlaždice v jednom kontejneru, nebylo možné dostat se k události dotyku běžnými prostředky, za což může interní implementace „ListView“, která s takovouto možností nepočítala. Celou situaci také komplikovalo časté volání obnovení obsahu „ListView“, protože při každém obnovení byly také uživatelské události zahozeny. Problém se podařilo vyřešit pomocí odchytávání doteku přímo v daných dlaždicích přes rozhraní „OnTouchListener“ a porovnáním s právě kliknutým virtuálním kontejnerem v seznamu pomocí rozhraní „OnItemClickListener“. Dále, pokud se uživatel zrovna dotýká obrazovky, je pozastaveno obnovování stavu dlaždic, dokud neuvolní prst z obrazovky. Po praktickém
58
testování se toto neukázalo jako závažný problém, neboť dotyková gesta trvají typicky pár sekund a nedojde k nějakým závažným prodlevám. Dlouhým stiskem vybraných dlaždic lze vyvolat dialog, který umožňuje nastavit hodnotu na zařízení v dlaždici. Dialog je řešen pomocí třídy „DialogFragment“. Jedná se tedy o speciální fragment obsahující v sobě klasický dialog a implementující metody pro jeho správu. Hlavním elementem je komponenta „SeekBar“, která slouží pro interakci s uživatelským dotekem. Pokud se uživatel dotkne kdekoliv v prostoru komponenty, dojde k nastavení příslušné hodnoty na zařízení a fragment zmizí. Pro dosažení takového chování je implementováno rozhraní „OnSeekBarChangeListener“, které obsahuje metody pro informování o současném stavu změny na komponentě „SeekBar“.
Obrázek 36 – Ukázka dialogu pro nastavené stmívání
5.3.1 Ovládání spotřebičů s pomocí náklonu zařízení Při promýšlení rozdílů ovládání mezi aplikací pro tablety a mobilní telefony, se ukázalo jako vhodné použít zabudované polohové senzory v mobilním telefonu. Tablety sice některé tyto senzory mají také, nicméně různě naklánět a otáčet tablet není příliš pohodlné. Pomocí těchto senzorů lze zjistit komplexní pozici telefonu v prostoru a mnohé další informace. Z tohoto důvodu bylo navrženo ovládání epsnet prvků typu „REAL“, typicky to jsou stmívače, náklonem zařízení podél horizontální osy. Náklonem doprava se nastavená hodnota na zařízení zvětšuje a analogicky náklonem doleva zmenšuje. Po praktickém testování se ukázalo vhodné omezit pro plynulejší změnu posuvníku indikace nastavené hodnoty maximální náklon zařízení na 25°. Pro registraci událostí ze senzorů slouží třída „SensorManger“. Pro zjištění náklonu vyhovujícímu navrženému ovládání bylo nutné využít informaci ze dvou typů senzorů –
59
akcelerometru a detektoru magnetického pole. Příjem událostí ze senzorů zajišťuje rozhraní „SensorEventListener“, konkrétně metoda „onSensorChanged ()“. //Zjisteni zda je mozne ziskat matici rotace boolean success = SensorManager.getRotationMatrix(inR, I, gravity, geomag); if (success) { //Ziskani rotace zarizeni SensorManager.getOrientation(inR, orientVals); //Prepocet uhlu natoceni z radianu na stupne roll = Math.toDegrees(orientVals[2]); //Omezeni maximalniho naklonu if(roll < 25) if(roll > -25) return; //Prepocet uhlu na vhodnou hodnotu zarizeni int b = (int) (bar.getProgress() + roll * 0.05); //Graficka reprezentace dat bar.setProgress(b); handleChangeProgress(b) }
Obrázek 37 – Ukázka zpracování dat ze senzoru Zde se vypočítá matice sklonu a rotace zařízení právě na základě dat z akcelerometru a magnetického senzoru. Z této matice se poté vypočte orientace zařízení vůči referenčním koordinátům. V posledním kroku je úhel náklonu přepočten na vhodnou hodnotu pro zobrazení v příslušném fragmentu. Konstanta pro přepočet byla zjištěna experimentálně tak, aby nedocházelo k příliš velkým skokům v nastavené hodnotě zařízení.
5.4
Další rozvoj
V rámci budoucího vývoje dojde k zapracování dalších modulů tak, aby se mobilní aplikace co do funkčnosti vyrovnala verzi pro tablet. Nicméně mobilní telefon nabízí mnohem širší možnosti využití, neboť jej povětšinu času člověk nosí u sebe. Tím se stává zařízením s rychlou odezvou a bylo by velice žádoucí mít možnost ovládat dům odkudkoliv. Zde se naráží na různá technologická omezení, například nutnost mít přístup na internet z mobilního telefonu. Rychlý rozvoj mobilního internetového připojení však tyto komplikace pomalu smazává. Pro možnost řízení domu odkudkoli by se musel upravit XML-RPC server, aby byl schopen přijímat zprávy i z internetu. S touto úpravou by ruku v ruce muselo přijít zvýšení bezpečnosti volání funkcí nejlépe s nějakou autentizací. Nicméně ani tato úprava by nevyřešila nutnost periodického dotazování se mobilního telefonu serveru na stav zařízení. Zde by se hodilo implementovat tzv. „push“ notifikace, jejichž implementaci od společnosti Google pod názvem „C2DM“[19] má každé zařízení s operačním 60
systémem Android. Princip funkce je velice jednoduchý. Aplikace by se zaregistrovala na webové službě společnosti Google a při změně stavu by vzdálený XML-RPC server uvědomil službu. Ta poté zašle všem zařízením, kterých se to týká, informaci o změně. Obrovskou výhodou tohoto řešení je jeho nízkoúrovňová implementace, přímo v jádru operačního systému, zaručující nízkou spotřebu energie a tím zachování baterie. Androidí aplikace
Služba C2DM
Notifikace aplikaci o změně Registrace na server
Komunikace aplikace se servem - ovládání domu.
Zaslání informace o změně stavu
XML-RPC server
Obrázek 38 – Řešení vzdálených notifikací v mobilní aplikaci
61
Závěr První část této diplomové práce se zabývala analýzou systému iNELS a iMM. Podrobně byly popsány nutné prostředky pro komunikaci mezi nimi a mobilním operačním systémem Android, který byl detailně popsán v navazující části. Byly představeny hlavní komponenty tvořící základ každé aplikace, bez kterých by byl další výklad komplikovaný. Důraz byl také kladen na grafické elementy nutné pro vytvoření efektního uživatelského rozhraní. V další části se nachází popis společných částí mobilní aplikace a aplikace pro zařízení typu tablet. Jedná se zejména o konfiguraci, komunikaci mezi systémy a licenční část. Současná implementace komunikace, kdy se program periodicky dotazuje serveru na aktuální stav hodnot, se po praktickém nasazení ukázala jako nepříliš vhodná. Objem dat komunikace je poměrně značný, což má nepříznivý vliv na stav baterie zařízení. Lepší variantou by bylo vytvoření serveru na mobilním zařízení, na který by stávající XML-RPC server zasílal informace, jen pokud by došlo ke změně stavu. První varianta aplikace byla určena pro zařízení typu tablet. Podle zadané grafiky byla vytvořena funkční aplikace obsahující moduly pro ovládání klimatizace, multimédií a kamer. Speciálním řešením je potom ovládání spotřebičů od firmy Miele závislé na přítomnosti externího webového serveru. Je zde detailně popsán systém vytváření a správy grafických elementů. Možným dalším vylepšením v grafice této varianty by bylo použití některé z pokročilých grafických komponent nedržící všecky objekty v paměti najednou. Další variantou aplikace je řešení pro mobilní telefony, které se podstatně odlišuje grafickým rozhraním a systémem ovládání. Bylo představeno řešení dle zadané grafiky a podrobně popsáno. Součástí kapitoly je i další rozvoj mobilní aplikace směřující ke vzdálenému ovládání a notifikacím.
62
Seznam literatury [1]
iRidium
Mobile. iRidium
for
iNELS [online].
2,
2012
[cit.
2012-04-27].
Dostupné
z:
http://www.iridiummobile.net/inelscom
[2]
Loxone. APP PRO IPHONE/IPAD A ANDROID [online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://www.loxone.com/Pages/cz/produkty/LoxAPP-ovl%C3%A1d%C3%A1n%C3%ADdom%C3%A1cnosti-iPhone/LoxAPP.aspx
[3]
Použití zařízení s OS Android pro ovládání systému iNELS. Praha, 2011. Semestrální projekt. ČVUT Praha, Fakulta elektrotechnická, Katedra měření. Vedoucí práce Ing. Jakub Šála.
[4]
ELKO EP s.r.o. Centrální jednotka CU2-01M [online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://www.inels.cz/nahled_png_no_border.php?soubor=media%2Fprodukty%2Fimg%2FCU201M.jpg&width=195
[5]
GOOGLE. Developer
Guide [online].
2,
2012
[cit.
2012-04-27].
Dostupné
z:
http://developer.android.com
[6]
GOOGLE. Application
Fundaments [online].
2,
2012
[cit.
2012-04-27].
Dostupné
z:
http://chart.apis.google.com/chart?&cht=p&chs=460x250&chd=t:0.3,0.7,5.5,20.9,0.5,63.9,0.1,1.0, 2.2,0.5,4.4&chl=Android%201.5|Android%201.6|Android%202.1|Android%202.2|Android%202.3| Android%202.3.3|Android%203.0|Android%203.1|Android%203.2|Android%204.0|Android%204.0 .3&chco=c4df9b,6fad0c
[7]
GOOGLE. System
architecture [online].
2,
2012
[cit.
2012-04-27].
Dostupné
z:
http://developer.android.com/images/system-architecture.jpg
[8] [9] [10] [11] [12] [13] [14] [15] [16] [17]
GOOGLE. View Hierarchy [online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://developer.android.com/images/viewgroup.png ORACLE. Threading in Java [online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://docs.oracle.com/javase/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html SQL CONSORTIUM. About SQL [online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://www.sqlite.org/about.html Wikipedie. XML-RPC [online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://en.wikipedia.org/wiki/XML-RPC Android-xmlrpc projekt. android-xmlrpc [online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://code.google.com/p/android-xmlrpc/ JSON. Úvod do JSON [online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://www.json.org/jsoncz.html JSON-RPC. JSON-RPC Specifications [online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://jsonrpc.org/wiki/specification SAMSUNG. Samsung Galaxy Tab[online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://www.samsung.com/cz/system/consumer/product/2010/09/30/gt_p1000cwaxez/01_large.jpg SAMSUNG. Samsung Galaxy Tab 10.1[online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://www.samsung.com/cz/system/consumer/product/2010/09/30/gt_p1000cwaxez/01_large.jpg Zobrazení obrazu z IP kamer v systému iTP Android. Praha, 2011. Semestrální projekt. ČVUT Praha, Fakulta elektrotechnická, Katedra měření. Vedoucí práce Ing. Jakub Šála.
63
[18]
[19]
SAMSUNG. Samsung Galaxy S2[online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: http://www.samsung.com/cz/system/consumer/product/2011/04/06/gt_i9100lkaxez/01_large_1.jp g GOOGLE. Android Cloud to Device Messaging Framework [online]. 2, 2012 [cit. 2012-04-27]. Dostupné z: https://developers.google.com/android/c2dm/#intro
64
Seznam obrázků Obrázek 1 - Centralizovaná systémy ......................................................................................... 10 Obrázek 2 – Distribuované systémy .......................................................................................... 11 Obrázek 3- Centrální jednotka CU2-01M[4] .............................................................................. 12 Obrázek 4 – Struktura paketu EPSNET UDP ............................................................................ 13 Obrázek 5 - Zpráva bez datového pole ...................................................................................... 14 Obrázek 6 - Zpráva s datovým polem ....................................................................................... 14 Obrázek 7 - Zpráva token ......................................................................................................... 14 Obrázek 8 - Struktura zprávy příkazu Real ............................................................................... 16 Obrázek 9 - Ukázka struktury dat ............................................................................................. 17 Obrázek 10 – Ukázka konfiguračního rozhraní systému iMM ................................................... 18 Obrázek 11 – Ilustrační zapojení všech prvků do funkčního celku ............................................ 19 Obrázek 12 – Používané verze operačního systému v procentuálním vyjádření......................... 21 Obrázek 13 - Schéma vnitřního uspořádání OS Android[7] ........................................................ 23 Obrázek 14 – Ukázka spouštění částí jiných aplikací ................................................................ 24 Obrázek 15 – Ukázka funkce zásobníku aktivit......................................................................... 25 Obrázek 16 – Životní cyklus aktivity ........................................................................................ 27 Obrázek 17 – Ukázka životního cyklu fragmentu...................................................................... 28 Obrázek 18 – Životní cyklus služeb. Vpravo spouštěné a vlevo navázané služby ...................... 29 Obrázek 19 – Ukázka souboru manifest přímo z aplikace ......................................................... 32 Obrázek 20 – Ukázka hierarchie grafických komponent [8] ........................................................ 35 Obrázek 21 – Ukázka použité xml souboru s definicí elementů ................................................ 35 Obrázek 22 – Orientační schéma hromadného čtení prvků z centrály CU2-01M ....................... 41 Obrázek 23 – Ukázka čtení dat z centrály CU2-01M ve vlákně ................................................. 41 Obrázek 24 – Ukázka použití XML-RPC knihovny .................................................................. 42 Obrázek 25 – Postupné volání funkcí pro stažení dat ................................................................ 43 Obrázek 26 – Ukázka licencování ............................................................................................. 45 Obrázek 27 – Zařízení „Samsung Galaxy Tab“[15] a „Samsung Galaxy Tab 10.1“[16] ................ 46 Obrázek 28 – Ukázka grafického rozhraní hlavní obrazovky tabletu ......................................... 47 Obrázek 29 – Ukázka grafiky ikony meteostanice .................................................................... 48 Obrázek 30 – Ukázka řešení nastavení hodnoty prvků „REAL“ ................................................ 49 Obrázek 31 – Dialog klimatizace se zobrazenými všemi moduly .............................................. 51 Obrázek 32 – Obecná kostra grafiky multimédií ....................................................................... 52 Obrázek 33 – Ukázka grafického rozhraní ovládání kamer ....................................................... 55 65
Obrázek 34 – Ukázka grafického rozhraní hlavní obrazovky mobilního telefonu ...................... 57 Obrázek 35 – Ukázka xml souboru s animací ........................................................................... 58 Obrázek 36 – Ukázka dialogu pro nastavené stmívání .............................................................. 59 Obrázek 37 – Ukázka zpracování dat ze senzoru ...................................................................... 60 Obrázek 38 – Řešení vzdálených notifikací v mobilní aplikaci ................................................. 61
66
Seznam tabulek Tabulka 1 - Popis polí v ESPNET UDP paketu ......................................................................... 13 Tabulka 2 - Význam použitých zkratek..................................................................................... 15 Tabulka 3 - Popis datového pole funkce ident ........................................................................... 16 Tabulka 4 – Jednotlivé verze OS Android spolu s charakteristikou ........................................... 22 Tabulka 5 – Ukázka URI pro získání dat z komponenty „Content Provider“ ............................. 30 Tabulka 6 – Názvy komponent ................................................................................................. 32 Tabulka 7 – Typy složek pro datové zdroje ............................................................................... 33 Tabulka 8 – Kvalifikátory založené na vlastnostech displeje ..................................................... 34 Tabulka 9 – Přehled komunikačních vláken .............................................................................. 39 Tabulka 10 – Seznam objektů pro grafickou reprezentaci ......................................................... 44 Tabulka 11 – Přehled hlavních vlastností referenčních zařízení ................................................ 47 Tabulka 12 – Stavy klimatizace ................................................................................................ 50 Tabulka 13 – Vlastnosti referenčního telefonu Samsung Galaxy S2 spolu s jeho obrázkem[16] .. 56
67
Seznam zkratek iOS – mobilní operační systém vyvinutý společností Apple Inc. PLC – „programmable logical controller“, malý průmyslový počítač CIB – „common installation bus“, název sběrnice používané systémem iNELS LED – „light emitting diod“, speciální dioda vyzařující světlo UDP – „user datagram protocol“, protokol pro přenos dat po síti TCP/IP - protokol pro přenos dat po síti SIP – „session initiation protocol“, protokol pro přenos signalizace v internetové telefonii VOIP – „voice over internet protocol“, protokol určený pro přenos hlasu po síti API – „application programming interface“, rozhraní pro přístup k aplikacím3339 XML – „extensible markup language“, obecný značkovací jazyk XML-RPC – protokol pro vzdálené volání procedur s použitým xml formátování JSON – „javaScript object notation“, způsob zápisu dat nezávislý na platformě JSON-RPC – protokol pro vzdálené volání procedur s použitým json formátování SQL – dotazovací jazyk pro práci v relačních databázích SOAP – „simple object access protocol“, protokol pro výměnu dat ve formátu xml H.264 – formát pro kompresi videa MPEG-4 - formát pro kompresi videa GPRS – „general packet radio service“, mobilní datová služba pro GSM mobilní telefony 3G - označení pro mobilní sítě třetí generace JPG
– formát komprese obrázků
DPI – „dots per inch“, údaj určující kolik obrazových bodů se vejde do jednoho palce
68
Obsah CD Součástí přílohy nejsou zdrojové kódy aplikace, neboť podléhají autorským právům společnosti Elko EP s.r.o.
/docs
textová část práce
/manuals
příručky a uživatelské manuály
69
