Sem vložte zadání Vaší práce.

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra Softwarového inženýrství Bakalářská práce VoIP videovrátný pod systémem Android Jan Maršoun Vedoucí práce: Josef Gattermayer 13. května 2013

Poděkování Především bych chtěl poděkovat vedoucímu práce za skvělý přístup. Dále děkuji všem svým blízkým za podporu v několika posledních nelehkých měsících.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 13. května 2013.....................

České vysoké učení technické v Praze Fakulta informačních technologií 2013 Jan Maršoun. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Maršoun, Jan. VoIP videovrátný pod systémem Android. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

Abstract This thesis describes the development of a system which provides communication with IP intercoms via SIP protocol and viewing image from cameras via RTSP protocol. Since the chosen hardware enviroment is a tablet with Android, so the basic introduction to the development of applications for this platform was included. The phases of development were Analysis, Design and Implementation. The result is a system which consists of two applications and whose functionality exceeds the task. Keywords Android, SIP, VoIP, RTSP ix

Abstrakt Tato práce provádí čtenáře vývojem systému, který zajišťuje komunikaci s IP interkomy prostřednictvím SIP protokolu a prohlížení obrazu z kamer přes RTSP protokol. Jelikož je jako hardwarové prostředí vybrán tablet s operačním systémem Android, tak bylo do práce také zařazeno základní seznámení s vývojem aplikací pro tuto platformu. Vývoj postupně prošel fázemi Analýza, Návrh a Realizace. Výsledkem je systém skládající se ze dvou aplikací, který funkcionalitou přesahuje zadání. Klíčová slova Android, SIP, VoIP, RTSP x

Obsah Úvod 1 1 Motivace 3 1.1 Současné způsoby řešení.................... 3 1.2 Motivace pro návrh řešení................... 4 2 Dané hardwarové prostředí 5 3 Protokol SIP 7 4 Analýza 9 4.1 Model případů užití....................... 9 4.2 Rešeršní studie opensource SIP klientů............ 11 5 Specifika vývoje aplikací pro OS Android 15 6 Návrh 25 6.1 Návrh aplikace VoIP Vrátný.................. 26 6.2 Návrh aplikace Kamery..................... 30 6.3 Návrh společný pro obě aplikace................ 33 7 Realizace 37 7.1 Použitý software třetích stran................. 37 7.2 Realizace aplikace Kamery................... 38 7.3 Realizace aplikace VoIP Vrátný................ 47 Závěr 55 xi

Literatura 57 A Seznam použitých zkratek 61 B Obsah přiloženého DVD 63 xii

Seznam obrázků 2.1 IP interkom 2N Helios IP Vario[22]............... 6 2.2 Tablet Ainol Novo 7 Crystal[25].................. 6 4.1 Případy užití systému pro koncového uživatele.......... 10 4.2 Případy užití systému pro administrátora............. 10 4.3 Prostředí aplikace SipDroid[19].................. 12 4.4 Prostředí aplikace LinPhone[20].................. 13 4.5 Prostředí aplikace CSipSimple[3]................. 13 5.1 Životní cyklus Activity[23]..................... 20 5.2 Životní cyklus Activity[23]..................... 21 5.3 Životní cyklus Service[23]..................... 22 6.1 Případy užití aplikace VoIP Vrátný................ 26 6.2 Diagram aktivit pro VoIP Vrátný................. 27 6.3 Případy užití aplikace Kamery................... 30 6.4 Diagram aktivit aplikace Kamery................. 31 6.5 Diagram aktivit pro získávání náhledů kamer.......... 32 6.6 Diagram aktivit pro vzdálenou synchronizaci VoIP Vrátného.. 34 6.7 Diagram aktivit pro vzdálenou synchronizaci aplikace Kamery. 35 7.1 Uživatelské protředí Fragmentu NoCamsFragment........ 39 7.2 Uživatelské protředí Fragmentu CamPreviewFragment..... 40 7.3 Uživatelské protředí Fragmentu CamVideoFragment....... 40 7.4 Uživatelské protředí Fragmentu AddCamsFragment....... 41 7.5 Uživatelské protředí Fragmentu SettingsFragment........ 42 7.6 Implementované widgety...................... 48 7.7 Uživatelské prostředí hlavní obrazovky.............. 49 xiii

7.8 Uživatelské protředí pro nastavení SIP účtu........... 49 7.9 Uživatelské protředí nastavení VoIP Vrátný........... 50 7.10 Uživatelské protředí příchozího hovoru před provedením změn. 51 7.11 Uživatelské protředí příchozího hovoru po provedením změn.. 51 7.12 Uživatelské protředí hovoru před provedením změn....... 52 7.13 Uživatelské protředí hovoru po provedením změn........ 53 xiv

Úvod Cílem práce je navrhnout a vytvořit systém pro dotykové tablety, který bude fungovat jako domovní vrátný a prohlížeč kamer. První část práce se zabývá představením a porovnáním současných možností řešení problému a je zde vysvětleno, proč má systém navržený v této práci předpoklady pro praktické využití. Práce pokračuje představením daného hardwarového prostředí a úvodem do protokolu SIP. Následuje analýza, ve které jsou popsány případy užití, které určují funkční požadavky na systém. Na konec této kapitoly je zařazena rešeršní studie opensource SIP klientů, jenž má za cíl vybrat vhodnou aplikaci, na jejímž přepracování bude založena implementace systému. Dále je v práci věnován prostor základnímu přehledu o vývoji aplikací pro operační systém Android. Z důvodu rozsáhlosti problematiky vývoje pro tuto platformu je přehled zúžen jen na tu část, která je pro práci významná a je v ní použita. V kapitole návrh je popsáno, jak by měl systém fungovat a zároveň je to vysvětleno diagramy aktivit. Také je zde podstatná část věnována návrhu uživatelského prostředí. Kapitola realizace se věnuje implementaci systému. V první části této kapitoly je prezentováno výsledné uživatelské prostředí a popsána jeho implementace. V druhé části jsou stručně popsány jednotlivé implementované balíky a důležitá funcionalita v nich je popsána detailněji. Výsledkem práce je funkční a stabilní systém, který stačí jen nainstalovat na dané zařízení. Tento systém dokáže komunikovat s IP interkomem Helios od firmy 2N a plně nahrazuje funkci vrátného. Zároveň je schopný přehrávat video přenášené přes RTSP ve formátu H264 z IP sítě a tím zobrazovat obraz z kamer v reálném čase. 1

Kapitola 1 Motivace 1.1 Současné způsoby řešení Dnes je používání dveřních interkomů běžné u firemních objektů a bytových domů, kde má majitel povinnost zajistit instalaci alespoň hlasového interkomu. Dveřní interkom slouží jako náhrada klasického zvonku. Dokáže zprostředkovat vzdálenou komunikaci mezi člověkem stojícím u interkomu a druhým člověkem u přijímacího zařízení. Komunikace může být jen zvuková a nebo může jít o videohovor. Pro účely této práce se počítá s případem, kdy majitel nemovitosti má zájem mít dům zabezpečen moderním kamerovým systémem a dveřním interkomem s přenosem videa. To by si ještě před několika lety žádalo poměrně velké investice do infrastruktury, protože každé takové zařízení by potřebovalo vlastní koaxiální kabel. Zároveň je do každého bytu obvykle třeba zavést telefon a televizi, což znamená další kabeláž navíc. Dnes je trendem vést všechny uvedené signály po jedné strukturované kabeláži a tím šetřit náklady. Moderní kamery pracují na bázy RTSP 1 proudů s vysokým rozlišením a jsou zapojeny do IP 2 síťě. Stejnou technologii jde využít i u dveřních interkomů a tím si ušetřit propojování každého jednotlivého bytu s interkomem pomocí samostatného kabelu. K obsluze vzdáleného odemykání dveří se zde využívá principu VoIP 3 telefonie. 1 Real Time Streaming Protocol (RTSP) je protokol pracující na aplikační vrstvě, který zajišťuje doručení dat, které jsou potřeba doručit v reálném čase.[13] 2 Internet Protocol (IP) zajišťuje přenos bloků dat nazvaných datagramy ze zdroje do cíle, přičemž zdroj a cíl jsou hostitelé definovaní adresou fixní délky.[12] 3 Voice over IP (VoIP) umožnuje uživatelům přenos zvukového proudu (například telefonní hovor) přes IP síť.[11] 3

1. Motivace 1.2 Motivace pro návrh řešení Systém, jehož vytvoření je cílem této práce, má cíl spojit IP telefon pro obsluhu dveřního IP interkomu a přehrávač videa z kamer do jednoho zařízení. Tímto zařízením má být tablet s operačním systémem Android. Dnes už má téměř každý tablet výbavu, která splňuje požadavky pro fungování domovního vrátného. Tyto požadavky jsou: Displej s kvalitním rozlišením Mikrofon Možnost připojení k IP síťi ať už pomocí WiFi, ethernet nebo USB portu Pokud pro účely srovnání vezmeme některé z levnějších tabletů, například Novo7 Crystal[25] od výrobce Ainol, tak v porovnání se zařízeními na obsluhu VoIP interkomů, které jsou v tuto chvíli na trhu dostupné, tablety vítězí moderním vzhledem, výbavou a cenou. Na jedné straně máme štíhlá zařízení s velkým displejem, na druhé zařízení připomínající klasický telefon s displejem obvykle o několik palců menším a vyšší cenou. Na trhu se také vyskytují čínské alternativy, které designem tablety připomínají. Většinou ale cena u těchto zařízení není naproti tabletům nijak výhodná. Za menší cenu lze získat tablet, který plně nahradí IP videotelefon a zároveň nám umožní kontrolovat kamery, na což bychom jinak potřebovali ještě další zařízení. Navíc získáváme možnost budoucího vylepšování funkčnosti tohoto zařízení pomocí aktualizace softwaru. 4

Kapitola 2 Dané hardwarové prostředí Jako dveřní interkom, pro který je výsledek této práce optimalizován, byl vybrán Helios IP Vario[22] od společnosti 2N[21]. IP interkom Helios využívá protokol SIP 4 pro navazování spojení s IP telefony a funguje jako SIP klient. Pokud je zapotřebí funcionalita SIP serveru, je třeba použít například systém Asterisk[27]. Podporované audio kodeky jsou G.711 PCM a G.729. Zvolený interkom dokáže posílat obraz ve formátu H.264 a H.263. Jedná se o klasický příklad VoIP telefonie. Jako tablet, pro který bude systém optimalizován, byl vybrán Novo7 Crystal[25] od výrobce Ainol. Tento typ tabletu je dodáván s OS 5 Android verze 4.1.1 a jeho cena je v tuto chvíli pod hranicí tři tisíce korun. Novo7 Crystal splňuje veškeré požadavky pro tuto práci. Výkon má dostatečný na to, aby přehrál video ve Full HD rozlišení. Displej je velký 7" a rozlišení, které displej dokáže zobrazit je 1024x600 bodů. 4 Session Initiation Protocol (SIP) je protokol pracující na aplikační vrstvě na vytváření, modifikování a ukončování spojení s jedním nebo více účastníky.[15] 5 Operační systém 5

2. Dané hardwarové prostředí Obrázek 2.1: IP interkom 2N Helios IP Vario[22] 6 Obrázek 2.2: Tablet Ainol Novo 7 Crystal[25]

Kapitola 3 Protokol SIP SIP je zkratka pro Session Initiation Protocol, což je možné do češtiny přeložit jako protokol pro zahájení relace. SIP se používá jako signalizační protokol, jehož hlavní funkce je vytvoření spojení mezi dvěma koncovými body pomocí kodeků a protokolů, které jsou oba koncové body schopné zpracovat. SIP dnes patří mezi nejrozšířenější signalizační protokoly a jeho hlavní využití je v internetové telefonii, kde zajišťuje VoIP spojení. Je definován v RFC3261 [15]. SIP je textový protokol, který je strukturou podobný například protokolu HTTP 6. Textová forma protokolu usnadňuje ladění a je důvodem snadné rozšiřitelnosti protokolu. Zasílané textové zprávy se dělí na požadavky a odpovědi. Typy požadavků jsou: Invite, Ack, Register, Cancel, Bye. Odpovědi jsou značené trojcifernými čísly a jdou rozděleny do šesti skupin podle významu a tyto skupiny poznáme podle prvního čísla z trojčíslí. Zprávy se skládají z definice typu zprávy a položek ve formátu <název>:<hodnota>, ve kterých jsou potřebné informace. SIP je navržen jako klient-server protokol, který funguje na aplikační vrstvě. K určení koncových bodů spojení se používá SIP URI 7, která nejčastěji používá formát sip:<uživatel>@<doména>. SIP server obvykle zajišťuje registraci koncových bodů, zjišťování jejich dostupnosti a je prostředníkem při navazování spojení. SIP je možné používat i jako klient-klient protokol, tím se ale připravíme o možnost plně využívat veškerou možnou funkcionalitu protokolu. 6 Hypertext Transfer Protocol (HTTP) je protokol pracující na aplikační vrstvě pro distribuované a spolupracující informační systémy.[14] 7 Uniform Resource Identifier (URI) je kompaktní sekvence znaků, která indentifikuje abstraktní nebo fyzický zdroj.[17] 7

Kapitola 4 Analýza 4.1 Model případů užití Model případů užití, neboli Use Case Model, znázorňuje funkční požadavky a zobrazuje interakce mezi uživateli a systémem. 4.1.1 Uživatelské role Uživatelské role tohoto systému jsou: Koncový uživatel Administrátor 4.1.1.1 Koncový uživatel Koncový uživatel má možnost si vybrat jednu z administrátorem nastavených kamer a na displeji sledovat, co se momentálně odehrává v jejím zorném poli. Může také kliknout na jedno z nastavených tlačítek pro komunikaci s IP interkomem a tím aktivovat spojení, ve kterém je možné vzdáleně pozorovat dění před kamerou interkomu a případně vzdáleně odemknout dveře. Dalším případem užití je signalizace příchozího hovoru a následné přijmutí hovoru koncovým uživatelem. Případy užití pro koncového uživatele jsou uvedeny na diagramu 4.1. 4.1.1.2 Administrátor Administrátor se od uživatele odlišuje znalostí administrátorského hesla, čímž získává přístup do nastavení systému. Jeho povinností je zajišťovat, 9

4. Analýza Obrázek 4.1: Případy užití systému pro koncového uživatele Obrázek 4.2: Případy užití systému pro administrátora 10

4.2. Rešeršní studie opensource SIP klientů aby na všech zařízeních bylo správně nastaveno spojení s interkomy a kamerami. Má možnost to provádět buď pro každé zařízení zvlášť a nebo pomocí vzdálené synchronizace pro všechny zařízení najednou. Případy užití pro administrátora můžete vidět na diagramu 4.2. 4.2 Rešeršní studie opensource SIP klientů Výsledkem této práce bude systém, který dokáže obsluhovat IP interkom Helios od spolešnosti 2N představený v kapitole 2. Vzhledem k tomu, že bylo rozhodnuto vyvíjet na platformě OS Android a implementace SIP klienta by byla hodně časově náročná, nabízí se využít nějakou stabilní existující opensource aplikaci jako základ pro návrh a implementaci. Aplikace vybraná na základě této rešeršní studie bude přepracována tak, aby její uživatelské prostředí bylo přímo přizpůsobeno k ovládání IP interkomů a bylo maximálně jednoduché a intuitivní. Do aplikace bude také implementována další funkcionalita, která bude pro účely této práce potřebná. Při hledání a následném testování vhodné aplikace byl kladen důraz na stabilitu pod OS Android verze 4.0 a vyšší a na to, aby byla kompatibilní s hardwarovým prostředím zvoleným pro tuto práci. Dalším důležitým ukazatalem bylo, zda je aplikace stále ve vývoji a jak aktivní jsou v opravování případných chyb vývojáři. Důkladným průzkumem SIP klientů, kteří podle Google Play měli splňovat všechny požadavky, byly do testování zařazeny tyto tři aplikace: Lin- Phone [36], SipDroid [40] a CSipSimple [31]. 4.2.1 SipDroid SipDroid se jevil jako nejslabší z trojice kandidátů. Hlavním nedostatkem bylo, že se v průběhu testování nepodařilo navázat stabilní videohovor. Dalším nedostatkem bylo, že možnosti nastavení nebyly nijak široké a nebylo možné nastavit lokální SIP účet, tedy volání bez SIP serveru. Po dobu testování došlo také několikrát k nestabilitě celé aplikace. 4.2.2 LinPhone LinPhone byl o poznání kvalitnější kandidát. V průběhu testování byl stabilní. Videohovory byly až na vyjímky, které byly způsobeny nekompatabilitou s některými internetovými SIP operátory, v pořádku. Jediné nedostatky, které byly zaznamenány, byl méně kvalitní přenášený zvuk a opět nemožnost nastavení lokálního SIP účtu. 11

4. Analýza Obrázek 4.3: Prostředí aplikace SipDroid[19] 4.2.3 CSipSimple U CSipSimple nebyly zaznamenány žádné velké nedostatky. Jako jediný dokonce umožnoval nastavení lokálního SIP účtu bez nutnosti přihlašování se k SIP serveru. V základní aplikaci nebyly dostupné videohovory, ale ke stažení je k dispozici plugin, který tento nedostatek napravuje. Podpora kodeků byla u tohoto SIP klienta největší, což může být důležité v případě, kdyby se výsledek této práce měl použít s jiným IP interkomem než s Helios 2N. 4.2.4 Zvolené řešení Na základě studie bylo rozhodnuto, že se pro účely této práce využije CSip- Simple. Jak bylo uvedeno v kapitole, která se tomuto SIP klientu věnovala, tato aplikace se při testování projevovala jako stabilní a podporuje vše, co je důležité. Jediné mínus je nutnost integrace pluginu přímo do aplikace. 12

4.2. Rešeršní studie opensource SIP klientů Obrázek 4.4: Prostředí aplikace LinPhone[20] Obrázek 4.5: Prostředí aplikace CSipSimple[3] 13

Kapitola 5 Specifika vývoje aplikací pro OS Android V této kapitole jsou stručně popsány specifika vývoje aplikací pro OS Android. Nejprve jsou uvedeny základní informace o aplikacích a poté jsou rozebrány důležité části aplikačního Android frameworku. Pozornost je věnována především těm částem frameworku, které budou použity při návrhu a implementaci systému, kterému se tato práce věnuje. 5.0.5 OS Android a aplikace OS Android je navržen tak, aby se maximálně omezil vzájemný vliv aplikací na fungování aplikací ostatních. Aplikace se pod OS Android dají přirovnat k uživatelům na OS Linux. Každá aplikace dostane od OS Android přiděleno unikátní ID a všem souborům aplikace jsou přidělena práva tak, aby k nim mohla pouze aplikace se správným ID. Aplikace v OS Android je spuštěna ve vlastním procesu, ve kterém běží ve VM 8, čímž je dosaženo toho, že je běžící aplikace v izolaci od ostatních aplikací. Aplikace v OS Android jsou z bezpečnostních důvodů omezeny na přístup jen do těch částí OS Android a uložených dat, které jsou potřebné pro chod aplikace. Práva pro přístup k systémovým zdrojům jsou definována v souboru AndroidManifest.xml, který je pro každou aplikaci unikátní. Všechna oprávnění jsou přidělena při instalaci a později je nejde měnit. 8 Virtual Machine (VM) je sftwarové prostředí, které vytváří mezivrstvu mezi kódem spuštěným uvnitř a softwarem nebo hardwarem venku. 15

5. Specifika vývoje aplikací pro OS Android 5.0.6 Vývoj aplikace pro OS Android Pro psaní aplikací pro operační systém Android se používá programovací jazyk Java a pro konfigurační soubory jazyk XML. Aplikace se kompilují pomocí Android SDK[5] a výsledkem kompilace je soubor s příponou apk. Tento soubor stačí nahrát na dané zařízení a při jeho spuštění se otevře instalační aplikace systému Android, která aplikaci nainstaluje. Pro vývoj aplikací se používá aplikační framework, který vývojářům aplikací pro OS Android umožňuje v rámci pravidel OS přistupovat například ke kontrole hardware zařízení, řídit některé procesy běžící na pozadí, přistupovat ke kontaktům v zařízení, nebo vkládat upozornění na hlavní lištu. Vývojáři mají díky aplikačnímu frameworku přístup ke stejnému API, které používají aplikace přímo integrované do OS Android 9. 5.0.7 Android Manifest AndroidManifest.xml je soubor, který musí mít každá aplikace pro OS Android a operační systém jej čte vždy před instalací a spuštěním aplikace. Tento soubor obsahuje základní informace důležité pro OS ke spuštění aplikace. AndroidManifest.xml mimo jiné slouží pro: Definici minimálních oprávnění důležitých k chodu aplikace Definici minimálního Android API potřebné ke spuštění aplikace. Definici jména aplikace Definici všech komponent aplikace (Activity (kapitola 5.0.9), Service (kapitola 5.0.11), Broadcast Reciever[28], Content Provider[29]) 5.0.8 Uživatelské prostředí Uživatelské prostředí aplikací v OS Android se skládá z jednotlivých View, kterým je věnována samostatná podkapitola 5.0.8.1. View mohou být definovány pomocí XML souborů, což je doporučený postup, nebo mohou být nadefinována přímo v kódu. Veškeré definiční soubory použité pro tvorbu uživatelského rozhraní se umisťují do adresáře /res v hlavním adresáři vývojového projektu. Adresář /res obsahuje předem definované podadresáře, které jsou určeny k ukládání specifických věcí. Předem definované podadresáře /res jsou: 9 Například: Google Play, Hodiny 16

layout - Obsahuje XML soubory použité pro definici View. drawable - Obsahuje obrázky, ikony, nebo XML soubory, pomocí kterých se dají definovat jednoduché obrázky. menu - Obsahuje XML soubory použité pro definici nabídek. values - Obsahuje XML soubory, ve kterých se definují různé hodnoty pro různé identifikační řetězce. Tato složka se využívá například pro implementaci překladů aplikace do více jazyků (více v kapitole 5.0.8.3). xml - Obsahuje XML soubory, které jsou použity pro vývoj aplikace a nepatří do žádné z předchozích kategorií. raw - Obsahuje jakékoli soubory, které se nehodí do předchozích kategorií. Od OS Android verze 3.0 je v aplikačním frameworku přítomna ActionBar[1]. ActionBar je lišta, která je určena pro použití na tabletech, které většinou nemají hardwarová tlačítka, používaná například pro vyvolání menu. Na ActionBar je možné umístit tlačítka, která mohou měnit svojí funcionalitu v různých částech aplikace. Zároveň ActionBar může sloužit k usnadnění orientace, protože na ní může být viditelné uživatelovo umístění v aplikaci. 5.0.8.1 View View je základní stavební jednotkou uživatelského rozhraní v OS Android. View je třída, ze které dědí všechny použitelné části uživatelského prostředí a zobrazuje se jako prostý obdélník. Potomkem View jsou mimo jiné: TextView - Prosté zobrazení textu Button - Zobrazení tlačítka s popisem ImageView - Zobrazení obrázku Pro obalení více View do jednoho je ve frameworku přítomna třída View- Group, která je také potomkem View. Použití ViewGroup je důležité například ve chvíli, kdy počet View na obrazovce není stálý. V této situaci se hodí použít vhodného potomka ViewGroup a naplnit ho pomocí instance potomka třídy Adapter [24]. Potomky ViewGroup jsou například: LinearLayout - Jednotlivá view řadí vedle sebe horizontálně, nebo vertikálně 17

5. Specifika vývoje aplikací pro OS Android RelativeLayout - Rozložení jednotlivých view je určeno v závislosti na okrajích RealtiveLayout a nebo v závislosti na jiných view v RealtiveLayout GridView - Jednotlivá view jsou řazena do matice 5.0.8.2 Optimalizace uživatelského prostředí pro různé displeje Optimalizace uživatelského prostředí pro displeje různých velikostí dosáhneme využitím modifikátorů ve jménech adresářů. Mezi modifikátory patří například: <port,land> - Pokud je zařízení v režimu na výšku použije se port, pokud v režimu na šířku použije se land. <l,m,h,x>dpi - Určující je hustota pixelů displeje zařízení. Použitelné hlavně pro obrázky. w<x>dp - Určující je dostupná šírka displeje. Tento modifikátor se používá například pro rozlišení, zda se jedná o tablet, nebo jiné zařízení. 5.0.8.3 Překlad aplikace do různých jazyků K vytvoření více lokalizací pro aplikaci se využívá adresář /res/values. Android framework standardně hledá vhodný soubor s uloženou lokalizací podle názvu souboru a podle aktuální nastavené lokalizace celého OS. Název adresáře /res/values může mít různé přípony značící, jaká lokalizace je v adresáři použita. Pokud je OS například nastavený na českou lokalizaci, tak se při hledání vhodného souboru Android nejprve podívá, jestli existuje soubor se správným názvem v adresáří /res/values-cs a pokud ano, tak ho použije. Pokud adresář neexistuje, nebo v něm neexistuje hledaný soubor, tak Android teprve začne hledat v adresáři /res/values, který slouží k uložení výchozí lokalizace. Tímto postupem je možné definovat jakýkoli jazyk a pro přidání dalšího jazyka do aplikace není většinou třeba vůbec zasahovat do kódu. 5.0.9 Activity Activity je třída, která je základním prvkem aplikace pro OS Android. Každá aplikace musí obsahovat alespoň jednu třídu, která je potomkem třídy Activity. Hlavním úkolem Activity je vytvoření uživatelského prostředí a interakce s uživatelem. Maximální počet potomků třídy Activity není v aplikaci 18

omezen. V kvalitně navržené aplikaci by každá Activity měla zajišťovat odlišnou funkcionalitu a jednotlivé Activity by na sobě měly být co nejvíce nezávislé. Každá Activity musí být deklarována v AndroidManifest.xml dané aplikace. V AndroidManifest.xml se také deklaruje, jaká Activity je použita jako spouštěcí pro danou aplikaci. Spouštěcí Activity se dá přirovnat k metodě main při programování konzolové aplikace v jazyku Java. Activity má od OS Android předem jasně definovaný životní cyklus. Ten je definovaný pomocí metod, které jsou spouštěny v předem definovaném pořadí. Životní cyklus Activity je společně s jeho metodami zobrazen na diagramu 5.1. Activity se může nacházet ve stavech: Bežící - Activity je v popředí a má možnost interakce s uživatelem. Pozastavená - Activity je alespoň částečně viditelná, ale nemá možnost interakce s uživatelem. Při nedostatku paměti může OS Android Activity v tomto stavu zničit. Zastavená - Activity je v pozadí a nemá možnost interakce s uživatelem. OS Android nezničil její objekt, protože je pravděpodobné, že se k Activitě uživatel bude chtít vrátit. Při nedostatku paměti může být objekt Activity zničen. 5.0.10 Fragment Od OS Android verze 3.0 je možné uživatelské prostředí jedné Activity rozdělit do více Fragmentů. Každý Fragment by měl zajišťovat zobrazení a obsluhu části uživatelského prostředí. Fragment je použitelný pouze ve spojení s Activity. Na obrázku 5.2 je znázorněno, jak je životní cyklus tříd Fragment a Activity propojen. Použití Fragmentů je důležité například v optimalizaci aplikace pro zařízení s různými velikostmi displeje. Obrazovka Activity se s jejich pomocí dá na zařízení se velkým displejem (tablet) rozdělit například na levou část s posuvnou nabídkou a pravou část, kde se zobrazují detaily o tom, co bylo v nabídce vybráno. Na zařízení s menším displejem (mobilní telefon) by aplikace vypadala tak, že by v jednu chvíli byl zobrazen jen Fragment s menu a po kliknutí na jednu položku by se tento Fragment překryl jiným s detaily o položce. 19

5. Specifika vývoje aplikací pro OS Android Obrázek 5.1: Životní cyklus Activity[23] 20

Obrázek 5.2: Životní cyklus Fragmentu[4] 21

5. Specifika vývoje aplikací pro OS Android Obrázek 5.3: Životní cyklus Service[9] 5.0.11 Service Service je třída, která je navržena k dlouhodobému běhu na pozadí. Service neposkytuje uživatelské prostředí a jeho běh není zavislý na běhu aplikace. Každý potomek třídy Service musí být deklarován v AndroidManifest.xml dané aplikace. Service je nastartován metodou startservice a běží v hlavním vlákně stejného procesu, ve kterém se aplikace spouští. Aplikace může se Service vytvořit spojení pomocí metody bindservice a je možné Service nastavit tak, aby s ním mohly komunikovat i ostatní aplikace. Stejně jako Activity má Service předem definovaný životní cyklus, který je definovaný pomocí metod spouštěných v přesném pořadí. Životní cyklus Service je zobrazen na obrázku 5.3. 5.0.12 AsyncTask Uživatelské prostředí aplikací pro OS Android běží na hlavním vlákně aplikace, ve kterém jsou některé operace zakázany, aby nenarušovaly plynulý 22

běh uživatelského prostředí. Mezi tyto operace patří například práce se sítí. AsyncTask je třída umožnující asynchronní vykonání jedné části dané operace ve vlastním vlákně a druhé části v hlavním vlákně pro uživatelské prostředí. AsyncTask se využívá například pro dialogy zobrazující průběh náhrávání, nebo pro ty operace, které nemohou být na hlavním vlákně spuštěny, ale nějak jej ovlivňují. AsyncTask je pomocná třída obalující mimo jiné i třídu Thread[42]. AsyncTask má čtyři metody, které jsou spouštěny postupně v předem daném pořadí. Tyto metody, uvedené v pořadí v jakém se spouští, jsou: 1. onpreexecute - Spuštěna na hlavním vlákně s uživatelským rozhraním. Používá se k inicializaci před hlavní operací a může například zobrazit stavovou lištu v uživatelském prostředí, aby měl uživatel přehled, v jaké části se spuštěná operace nachází. 2. doinbackgroud - Hlavní metoda AsyncTask, která je spuštěna hned po onpreexecute. Běží ve vlastním vlákně. 3. onprogressupdate - Metoda, která běží v hlavním vlákně s uživatelským prostředím. Její hlavní využití je informování o stavu, ve kterém se operace v doinbackground nachází. Informovat může například pomocí interakce se stavovou lištou vytvořenou v metodě onpreexecute. 4. onpostexecute - Spuštěna na hlavním vlákně uživatelským prostředím po tom, co se skončí metoda doinbackground. Po proběhnutí této metody se AsyncTask ukončí. 5.0.13 Widget V OS Android widgety slouží k přizpůsobení domovské obrazovky. Na domovské obrazovce může uživatel s widgety libovolně hýbat a od OS Android verze 3.1 mohou mít widgety uživatelem nastavitelnou velikost. Widgety obvykle slouží k zobrazování vybraných dat, které poskytuje aplikace, nebo k rychlému přechodu do aplikace z domovské obrazovky. 5.0.14 Android NDK Pro psaní aplikací pro OS Android se používá jazyk Java, ale pro určité části aplikace je možné také využít jazyk C/C++. Využití jazyku C/C++ by mělo být omezeno jen na nejnutnější případy a programátor by vždy měl nejprve zvážit, zda funkcionalitu, kterou chce využitím C/C++ získat, již neposkytuje aplikační Android framework. Využití C/C++ může být 23

5. Specifika vývoje aplikací pro OS Android výhodné například v případě, kdy už existuje rozsáhlá fungující knihovna v C/C++ a implementace této funkcionality v jazyku Java by byla časově náročná. Využití C/C++ pod OS Android zajišťuje Android NDK 10. NDK obsahuje nástroje pro generování nativních knihoven z kódu v jazyku C/C++ a zajištuje zahrnutí nativních knihoven do výsledného aplikačního apk souboru. 10 Native Development Kit 24

Kapitola 6 Návrh Kvalitní návrh architektury je klíčový pro úspěšné dokončení každého softwarového projektu. Mezi základní kameny návrhu patří shrnutí hlavních nefunkčních požadavků, na které bude kladen důraz. V případě této práce jsou nefunkční požadavky: Stabilita a Spolehlivost - Aplikace dokáže odolávat neočekávaným vstupům a chybám při kontaktu s uživatelem, komunikaci s interkomem či kameramy a také při vzdálené synchronizaci po síti. Uživatelský komfort - Uživatelské prostředí je jednoduché a intuitivní. Efektivita - Maximalizace využití aplikačního Android frameworku a využití více vláken. Důraz je také kladen na co nejmenší duplicitu kódu. Návrh systému se musel přizpůsobit zařízení, pro které je systém určen. Uživatelské prostředí je proto optimalizováno pro tablet s displejem o velikosti 7" a operačním systémem Android 4.0 a novějším. Na zpětnou kompatabilitu pro starší verze operačního systému Android není v této práci brán zřetel, protože počet tabletů s nižší verzí je zanedbatelný. Důraz je také kladen na jednoduchost případné další optimalizace na jinou velikost displeje. Základní úkoly systému, který je předmětem tohoto návrhu, jsou komunikace s dveřním IP interkomem a zobrazování obrazu z kamer. Jelikož jsou to dvě na sobě prakticky nezávislé činnosti, tak bylo rozhodnuto, že návrh systému bude rozdělen na aplikaci s názvem VoIP Vrátný, která bude zajišťovat obsluhu IP interkomu, a aplikaci Kamery, která se bude věnovat čistě jen práci s kamerami. Hlavním kladem tohoto rozdělení je, že jednotlivé 25

6. Návrh Obrázek 6.1: Případy užití aplikace VoIP Vrátný součásti systému budou použitelné nezávisle na sobě a také se tím minimalizuje riziko, že by případné selhání jedné nezávislé části systému mělo nějaký dopad na druhou část. 6.1 Návrh aplikace VoIP Vrátný VoIP Vrátný je SIP klient, který je přizpůsoben pro jeho jediný učel. Tímto účelem je komunikace s dveřním IP interkomem, což je také speciálně upravený SIP klient. Návrh aplikace je ovlivněn aplikací CSipSimple, která byla využita mimo jiné jako základ pro obsluhu SIP protokolu. Uživatelské prostředí této aplikace je třeba z velké části přepracovat a také je třeba navrhnout fungování aplikace jako celku, protože bude do aplikace přidávána nová funkcionalita. 26

6.1. Návrh aplikace VoIP Vrátný Obrázek 6.2: Diagram aktivit pro VoIP Vrátný 27

6. Návrh 6.1.1 Základní struktura Návrh základní struktury aplikace Vrátný vychází z funkčních požadavků, které jsou znázorněny na diagramu 6.1. Zárověn je přizpůsoben tak, aby co nejefektivněji využíval aplikační Android framework. Vstupním bodem aplikace je hlavní Activity, která zajišťuje správné spuštění a obsluhu všech ostatních Activit, Fragmentů a vláken. Při spuštění aplikace hlavní Activity jako první zajistí spuštění Service, která se stará o navazování a příjem komunikace přes SIP protokol. Dále detekuje, zda je aplikace spuštěna na daném zařízení poprvé a pokud ano, provede základní nastavení. Po nastavení aplikace je vytvořeno vlákno, které obstarává vzdálenou synchronizaci. Pokud Activity detekuje, že není nastaven SIP účet, zajistí zobrazení obrazovky, kde je možné účet pomocí několika kliků nastavit. Po dokončení inicializace aplikace je zobrazeno základní uživatelské rozhraní s tlačítky pro spuštění komunikace s interkomy. Základní struktura životního cyklu aplikace je znázorněna diagramem aktivit 6.2. Aplikační logiku při hovoru s IP interkomem zajišťuje vlastní Activity, kterou spoustí SIP Service buď na podnět hlavní aplikace, nebo kvůli příchozímu hovoru. Tato Activity zajištuje operace předcházející navázání spojení, jako je například zobrazení tlačítek pro příjem nebo odmítnutí hovoru, i hovor samotný. 6.1.2 Uživatelské prostředí 6.1.2.1 Prostředí hlavní aplikace V prostředí hlavní aplikace má uživatel možnost výběru z nabídky IP interkomů, se kterými může jediným kliknutím zahájit hovor. K tomu bude sloužit samostatný Fragment, který bude zajišťovat zobrazení tlačítka pro každý z nastavených interkomů a tato tlačítka bude obsluhovat. Maximální počet tlačítek je omezen na čtyři, protože vzhled této obrazovky bude třeba implementovat zvlášť pro každý různý počet tlačítek a je velmi nepravděpodobné, že bude třeba obsluhovat více jak čtyři interkomy najednou. V horní části obrazovky bude lišta, na které bude v levé části napsán název aplikace a v pravé části bude tlačítko pro vyvolání menu. Administrátor má díky znalosti hesla navíc možnost vstupu do nastavení aplikace a při prvním spuštění také do nastavení SIP účtu. V nastavení je možné jednoduše upravit adresy a popisy jednotlivých interkomů, adresu pro vzdálenou synchronizaci, zapnutí synchronizace a další nastavení týkající se vzhledu a fungování aplikace. 28

6.1. Návrh aplikace VoIP Vrátný Vzhled aplikace byl zvolen tak, aby byl maximálně jednoduchý a nevybočoval ze standardů systému Android. Barva tlačítek na hlavním uživatelském Fragmentu je světle zelená a pozadí pro dosažení kontrastu čistě černé. Activity zajišťující obrazovku nastavení je potomkem PreferenceActivity[38] z aplikačního Android frameworku a tím je stanoven i její vzhled, který je stejný jako vzhled nastavení celého OS Android. 6.1.2.2 Prostředí hovoru Pokud Service zajišťující obsluhu SIP protokolu detekuje příchozí hovor z IP interkomu, tak se zobrazí informační obrazovka. Zde je v horní části napsán název interkomu, ze kterého příchozí hovor pochází a pod tím zvolené logo. Ve spodní části jsou dvě velká tlačítka s popiskem akce, kterou zajišťují. Zelené pro příjem hovoru a červené pro odmítnutí. Obrazovka pro videohovor se automaticky naformátuje tak, aby došlo k zobrazení videa ve správném rozlišení. V horní části se nachází obraz videa, pod kterým je zelené tlačítko pro vzdálené odemknutí zámku a pod ním červené pro ukončení hovoru. 6.1.3 Obsluha SIP protokolu VoIP Vrátný musí být schopný přijímat hovory z IP interkomu nepřetržitě, a to i v případě, že aplikace není uživatelem přímo spuštěna. Pro splnění těchto požadavků je v systému Android možnost navrhnout service, který je spuštěn na pozadí hned po startu zařízení a zajišťuje obsluhu SIP protokolu. Service využívá WakeLock[37], a tím brání přechodu zařízení do režimu spánku. Protože návrh a implementace samotné Service pro obsluhu SIP protokolu by byly časově hodně náročné aktivity, je využit Service z aplikace CSipSimple. 6.1.4 Správa dat V této aplikaci je třeba ukládat nastavení SIP účtu a nastavení tlačítek. Nastavení SIP účtu je převzato z aplikace CSipSimple a pro jeho uložení je použita SQLite databáze. Nastavení tlačítek je ukládáno do SharedPreferences[10] aplikace. Tento způsob byl zvolen, protože je stanoven maximální počet tlačítek na čtyři a tím pádem je jednoduše proveditelný. Další výhoda tohoto způsobu je, že odpadá implementace ručního nastavování tlačítek, které jdou díky využité PreferenceActivity nastavit přímo z menu aplikace. 29

6. Návrh Obrázek 6.3: Případy užití aplikace Kamery 6.2 Návrh aplikace Kamery Aplikace Kamery je striktně zaměřena na jediný účel, kterým je zobrazení přehledu kamer a následné přehrávání obrazu z kamery v reálném čase. 6.2.1 Základní struktura Základní struktura aplikace Kamery je stejně jako u VoIP Vrátný navržena tak, aby co nejvíce využívala aplikační Android framework a zároveň splňovala všechny funkční požadavky na kamerovou část systému, které jsou znázorněny na diagramu 6.3 Je zde jedna hlavní Activity, která zajišťuje inicializaci aplikace a následné spouštění dalších podpůrných Fragmentů a vláken. Po spuštění aplikace hlavní Activity detekuje, zda už byla provedena základní inicializace nastavení a pokud nebyla, tak ji provede. Následuje spuštění synchronizačního vlákna a inicializace aplikace končí spuštěním Fragmentu, který se postará o zobrazení obrazovky s náhledy kamer. Tento Fragment při prvním spuštění v rámci běhu aplikace spustí samostatné vlákno na získávání náhledů kamer. Základní struktura životního cyklu aplikace je znázorněna diagramem aktivit 6.4. 30

6.2. Návrh aplikace Kamery Obrázek 6.4: Diagram aktivit aplikace Kamery 31

6. Návrh Obrázek 6.5: Diagram aktivit pro získávání náhledů kamer 6.2.2 Uživatelské prostředí Uživatelské prostředí v této aplikaci je tvořeno několika Fragmenty. Pro uživatele jsou důležité Fragmenty zobrazující náhledy kamer a Fragment se zobrazováním videa. Administrátor má, díky znalosti hesla, navíc přístup do Fragmentu s nastavením aplikace. V nastavení aplikace je možné například nastavit vzdálenou synchronizaci, aktualizaci aplikace, nebo smazat všechny uložené kamery. Je zde také možnost zapnout admin mód, který v aplikaci umožnuje vstup do Fragmentu pro přidávání kamer a umožnuje kamery editovat. Vzhled a barvy uživatelského prostředí je u aplikace Kamery velmi podobný aplikaci VoIP Vrátný. V horní části obrazovky je lišta s názvem aplikace a tlačítkem pro vyvolání menu. Pod ní je plocha s černým pozadím, kde se zobrazují náhledy. Fragment, který má tuto obrazovku na starosti, zajištuje, že náhledy jsou zde zobrazeny v posuvné tabulce o dvou sloupcích a jsou naformátovány vždy tak, aby na jednu obrazovku vyšly i s popiskem právě čtyři. Jedním kliknutím na zvolenou kameru se zobrazí Fragment s přehráváním videa. Aby se obraz kamery mohl zobrazovat v co největším okně, tak je v tomto framentu vypnuta horní lišta. 32

6.3. Návrh společný pro obě aplikace 6.2.3 Náhledy kamer Získávání náhledů kamer začne vždy při startu Fragmentu s přehledem kamer. Získávání probíhá asynchronně na samostatném vlákně, takže uživatelské prostředí aplikace by tím nemělo být nijak zpomaleno. Proces začíná získáním URL kamer z aplikační databáze. Dále jsou pro všechny kamery postupně předchozí náhledy nahrazeny novými. Nakonec je zaslán signál Fragmentu s náhledy, aby se aktualizoval a tím se zobrazily uživateli nové náhledy. Celý proces je znázorněn na diagramu 6.5. 6.2.4 Správa dat V aplikaci Kamery je potřeba ukládat dva typy dat. Zaprvé jsou to informace o kamerách a zadruhé obrázky náhledů kamer. Informace o kamerách, které se v aplikaci uchovávají, jsou URL a název, který je zobrazen pod náhledem a při přehrávání videa. Jelikož počet kamer, které může aplikace sledovat, není nijak omezen, jsou tyto informace uloženy do aplikační databáze. Jako databáze je použita SQLite, která je v Androidu přítomna a pro účely této práce bohatě stačí. Databáze obsahuje jedinou tabulku, která má tři sloupce: Id, URL a Název. Na obrázky náhledů kamer je v hlavním adresáři aplikačních dat vytvořena složka s názvem Pictures, do které jsou obrázky ukládány. 6.3 Návrh společný pro obě aplikace 6.3.1 Automatická synchronizace Důvodem existence automatické synchronizace aplikace je možnost vzdáleně hromadně ovládat nastavení jednotlivých aplikací. Tato funkcionalita se využije v případě, když je do systému přidán nebo odebrán jeden nebo více IP interkomů či kamer. Servisní technik pak nemusí obcházet každé zařízení. Stačí, když tuto změnu nastaví na jedno jediné místo a jednotlivá koncová zařízení se pak při spuštění nastaví sama. Jako protokol pro synchronizaci byl zvolen HTTP a nastavení bude dostupné ve formátu JSON[8]. HTTP i JSON jsou pro podobné účely ideální kvůli jejich jednoduchosti a spolehlivosti. Důležité je, že synchronizace je spouštena vždy po startu aplikace a běží asynchronně. Uživatel tedy po startu není zdržován čekáním na dokončení synchronizace a ani není poznat, že nějaká synchronizace probíhá. Pro zajištění synchronizace jsou vytvořena dvě vlákna. První se stará o kontrolu hlavního nastavení, které obsahuje URL pro stažení aktualizace 33

6. Návrh Obrázek 6.6: Diagram aktivit pro vzdálenou synchronizaci VoIP Vrátného aplikace a URL pro synchronizaci nastavení interkomů nebo kamer, která je využita druhým vláknem. Pokud byly nalezeny nějaké změny, tak se provede aktualizace, a pokud je to třeba, tak se zavolá signál pro změnu v uživatelském rozhraní. Tak se docílí toho, že uživatel uvidí aktuální data. Průběh synchronizace pro aplikaci VoIP Vrátný je znázorněn na diagramu 6.6 a pro aplikaci Kamery na diagramu 6.7. 6.3.1.1 Formát synchronizačních zpráv V systému jsou tři druhy synchronizačních zpráv: synchronizace hlavního nastavení, synchronizace kamer, synchronizace interkomů. Zprávy jsou zasílány jako pole informací ve formátu JSON. U synchronizace hlavního na- 34

6.3. Návrh společný pro obě aplikace Obrázek 6.7: Diagram aktivit pro vzdálenou synchronizaci aplikace Kamery stavení je zasláno jedno asociativní pole, ve kterém jsou uvedeny adresy pro synchronizaci kamer, synchronizaci interkomů a adresa pro aktualizaci aplikace. U synchronizace kamer a interkomů je zasláno vždy jedno indexované pole, které je naplněno asociativními poli reprezentující jednotlivé kamery či interkomy. 6.3.2 Aktualizace aplikace Po vzniku nové verze aplikace je nutné ji nahrát na všechna koncová zařízení. Ke zjednodušení tohoto procesu je aplikace schopná si ze zadané adresy v nastavení stáhnout instalační soubor a spustit instalaci. Práce ad- 35

6. Návrh ministrátora spočívá v tom, že do synchronizačního serveru zadá adresu pro aktualizaci a přesune se ke koncovému zařízení. To se samo synchronizuje a administrátor jen klikne na tlačítko v menu, které aktualizaci spustí. Po asynchronním stažení instalačního souboru je administrátor vyzván k potvrzení instalace. Tím dojde k přeinstalování aplikace bez ztráty jejího nastavení. 6.3.3 Widgety Pro obě aplikace byly navrženy widgety, které slouží ke spuštění aplikace přímo z hlavní plochy OS android. Widgety mají tvar barevných tlačítek s nápisem názvu aplikace a po kliku reagují změnou barvy. Widgety bude možné zvětšovat nebo zmenšovat. 36

Kapitola 7 Realizace Tato kapitola slouží k popisu implementace systému a k předvedení uživatelského prostředí. Nejprve je zde shrnut software třetích stran použitý pro implementaci systému. Následuje seznámení se s uživatelským prostředím a popis balíků aplikace. Z důvodu velkého počtu implementovaných tříd je detailní popis implementace omezen na klíčové a zajímavé části. 7.1 Použitý software třetích stran V implementaci systému byl použit software třetích stran. Byl použit v případech, kdy aplikační Android framework neposkytoval požadovanou funkcionalitu a vlastní implementace této funcionality by byla časově náročná. Ve využití softwaru třetích stran byl kladen důraz na to, aby využití vyhovovalo licenci, ve které je software distribuován. 7.1.1 CSipSimple CSipSimple[3] je aplikace pro OS Android použitá k implementaci aplikace VoIP Vrátný. Byla vybrána na základě rešeršní studie v kapitole 4.2 a VoIP Vrátný přejímá velkou část její funcionality. Aplikace je distribuována pod licencí GNU GPL[18]. 7.1.2 FFmpeg FFmpeg[33] je software usnadňující práci s videem a zvukem. V této práci je použit v implementaci aplikace Kamery, která ho využívá k vytváření náhledů kamer. FFmpeg byl použit, protože aplikační Android framework 37

7. Realizace neposkytoval tuto funcionalitu při práci s RSTP. FFmpeg je distribuován pod licencí GNU GPL[18]. 7.1.3 Gson Gson[6] je knihovna pro jazyk JAVA, která umožňuje konverzi Java objektů do formátu JSON a obráceně. Gson je použit pro vzdálenou synchronizaci obou implementovaných aplikací. Gson je distribuován pod licencí Apache Licence 2.0[16]. 7.2 Realizace aplikace Kamery Implementace aplikace Kamery vychází z návrhu v kapitole 6.2. 7.2.1 Uživatelské prostředí Uživatelské prostředí aplikace Kamery je složené ze čtyř částí: Obrazovka s náhledy kamer Obrazovka pro přehrávání videa Obrazovka pro přidávání kamer - dostupná pouze administrátorovi Nastavení - dostupné pouze administrátorovi Každá obrazovka je implementována pomocí jednoho nebo více Fragmentů. V aplikaci je implementována lišta, která je viditelná v horní části všech obrazovek kromě obrazovky pro přehrávání videa, kde je skryta, aby nezabírala prostor pro video. Lišta je implementována pomocí ActionBar[1] z aplikačního Android frameworku. Vzhled obrazovek a rozložení jednotlivých viditelných komponent na nich je v souladu s android frameworkem definován XML soubory v adresáři /res, který je umístěn v hlavním adresáři projektu. Implementace uživatelského prostředí byla optimalizována pro zařízení s velikostí displeje 7" a pro testovací účely také pro displeje s velikostí 4.3". Aby aplikace využívala možností aplikačního Android frameworku, jsou XML soubory s rozložením jednotlivých obrazovek umístěny do odpovídajících podsložek v adresáři /res. To vytváří prostor pro případné velmi jednoduché optimalizování uživatelského prostředí i pro jiné velikosti displejů. 38

7.2. Realizace aplikace Kamery Obrázek 7.1: Uživatelské protředí Fragmentu NoCamsFragment 7.2.1.1 Obrazovka s náhledy kamer První, co uživatel po spuštění aplikace uvidí, je obrazovka s náhledy kamer. Tuto část uživatelského prostředí zajišťují dva Fragmenty, které se nacházejí v balíku ui.videopreview. V případě, že v aplikační databázi nejsou žádné záznamy o kamerách, tak hlavní Activity vytvoří NoCamsFragment. Tento Fragment v metodě oncreateview použije pro tvorbu uživatelského prostředí definiční soubor no_cams_home.xml. Tím se vytvoří prostředí obsahující pouze jediné tlačítko uprostřed obrazovky, které uživatele po kliknutí přenese do obrazovky pro přidávání kamer. Metoda oncreateview před svým ukončením zkontroluje, zda je aplikace v admin módu, a pokud není, tak tlačítko uprostřed obrazovky skryje. Tím je docíleno stavu, kdy přidávat kamery může jen administrátor a nebo uživatel, kterému tuto činnost administrátor povolil. Uživatelské protředí Fragmentu NoCamsFragment je zobrazeno na obrázku 7.2. Pokud aplikační databáze obsahuje alespoň jednu nastavenou kameru, tak hlavní Activity vytvoří Fragment CamPreviewFragment. Tento Fragment v metodě oncreateview použije pro tvorbu uživatelského prostředí definiční soubor video_grid_preview.xml. Tím se vytvoří prostředí, které obsahuje GridView[7], které má v závislosti na použitém přístroji jeden nebo dva sloupce. K naplnění GridView daty je použit potomek třídy Adapter[24] VideoPreviewAdapter ze stejného balíku. Po naplnění GridView jsou uživateli zobrazeny všechny dostupné náhledy kamer s popisem, o jakou kameru se jedná. Tyto náhledy jsou rozmístěny do matice, která má pro 7" displej 39

7. Realizace Obrázek 7.2: Uživatelské protředí Fragmentu CamPreviewFragment Obrázek 7.3: Uživatelské protředí Fragmentu CamVideoFragment dva sloupce. Jednotlivé náhledy slouží jako tlačítka, která po stisknutí uživatele přenesou do obrazovky zajišťující přehrávání obrazu ze zvolené kamery. Pokud je aplikace v admin módu, tak má uživatel možnost dlouhým stiskem náhledu vyvolat nabídku, kde může jednotlivé kamery editovat nebo mazat. Uživatelské prostředí Fragmentu CamPreviewFragment je zobrazeno na obrázku 7.2. 40