Analýza systému Android ve vztahu ke klientské části informačních systémů

Analýza systému Android ve vztahu ke klientské části informačních systémů Ondřej Berger Univerzita Hradec Králové Fakulta informatiky a managementu – KIKM Hradecká 1249/6, Hradec Králové [email protected] Abstrakt: V oblasti mobilních technologií dochází v posledních měsících k poměrně bouřlivému rozvoji. Adaptabilita systému Android na různé druhy zařízení od mobilních telefonů, přes tablety až po subnotebooky mu dává zajímavou možnost ve využití jako platformy pro vývoj mobilního klienta informačních systémů. Tento článek se zabývá analýzou částí, ze kterých lze vytvořit aplikaci pro Android a významu těchto aplikačních komponent ve vztahu pro serverového klienta. Shrnuje jednotlivé části aplikace Android včetně technologií pro řešení výměny dat mezi systémem a klientem, a dává je do vztahu s požadavky na mobilního klienta. Mimo jiné se zabývá i aplikací kontextových informací a jejich využívání klientem. S ohledem na fakt, že Android využívá programovací jazyk Java, je provedeno i srovnání technologických možností s platformou J2ME. Klíčová slova: Android, architektura androidu, klient-server, REST, kontextové informace Abstract: There is a quite massive development in mobile technologies. Relatively new platform Android is becoming an interesting alternative for developing a client application for information systems because of its adaptability to various devices from cell phones to netbooks. Following text targets to analysis how to create a mobile client on Android and Android based application components. Android application parts and other important aspects (like context awarennes) are analysed in way how to use them as parts of mobile client. There is also a small development comparsion with Java Micro Edition because Android uses Java as its programming language. Keywords: Android, android architecture, client-server, REST, context-awarennes

1. Úvod Mobilní technologie v současnosti nabývají na významu. Dostupnost a možnosti mobilních zařízení se rozšiřuj a zároveň se jedná o rychle se rozvíjející prostředí. Jedním z takových mobilních prostředí je i operační systém Android. Právě možnosti této platformy, a její nasazení v různých druzích mobilních zařízení naznačuje, že by mohla být vhodnou alternativou k již zavedeným řešením pro tvorbu klientů informačních systémů. Jedná se tak o možné využití operačního systém Android jako prostředí, ve kterém budou spouštěny aplikace vystupující v roli klientů informačních systémů. Následující text stručně představí platformu Android a její komponenty, které lze použít k tvorbě aplikace. V souvislosti s těmito komponentami budou zároveň nastíněny možnosti těchto komponent k tvorbě aplikace, která bude sloužit jako klient SYSTÉMOVÁ INTEGRACE 4/2011

93

Ondřej Berger

informačního systému. Z tohoto vývojářského pohledu bude provedeno i srovnání s jednou z rozšířených mobilních platforem J2ME. Kromě toho budou představeny i způsoby řešení vzdálené komunikace a také využitelnost kontextu zařízení a jeho aplikace při tvorbě klienta IS. Zjištěné poznatky také budou dány do vztahu při zhodnocení vhodnosti celé platformy jak z hlediska ekonomického, tak zejména technologického. Tento text by měl pomoci při rozhodování, zda o využití systému Android jako prostředí pro realizaci klienta IS vůbec uvažovat a jaké jsou technologické možnosti, které Android jako systém nabízí.

2. Představení systému Android Operační systém Android, někdy nazývaný Google Android (ačkoliv za vývojem stojí celá skupina firem a uskupení, nikoliv pouze Google), je v současnosti jednou z nejdynamičtěji rozvíjejících se platforem oblastí v mobilních technologiích. Tento systém lze nalézt v široké škále zařízení, což dává možnost znovuvyužívat znalosti použité k vývoji klienta v různých situacích a projektech. Klient proto může být nasazen v mobilních telefonech, tabletech, ale též subnoteboocícch či netboocích. Cílové zařízení díky tomu může být zvoleno ideálně ve vztahu k řešené problémové doméně. Možnosti platformy totiž umožňují jednu aplikaci přizpůsobovat jak staticky tak dynamicky různým prostředím. Jednotlivá zařízení lze rozlišovat na základě například velikosti a rozlišení displeje, přítomnosti HW klávesnice apod. Dále se text bude věnovat těmto schopnostem a jejich možnou aplikací při realizaci klienta systému.

2.1 OHA Sdružení Open Handset Aliance sdružuje aktuálně kolem osmi desítek společností a firem, které zaštiťují a podílejí se na vývoji platformy Android. Mezi tyto společnosti patří jak mobilní operátoři (např. Telefónica, T-Mobile), tak softwarové společnosti (Google, eBay), ale i velké množství výrobců polovodičů a čipů (HTC, LG, Broadcom). Kromě těchto spoleností lze v OHA nalézt i společnosti s různými zaměřeními jako ARM či Atheros, kteří kupříkladu vyrábějí procesory nebo síťové karty.

2.2 Historie a verze Dnešní platforma Android začala být vyvíjena již před rokem 2005 ve společnosti Android Inc. V červenci roku 2005 přichází společnosti Google a kupuje celou společnost. V prosinci 2007 vzniká uskupení OHA (Open Handset Aliace), které sdružuje přes 80 společností – výrobců hardware, software, mobilních operátorů atd. a zaštiťuje vývoj platfromy. V září 2008 je uvolněn do prodeje první telefon s označením T-Mobile G1 a zároveň je uvolněn Source Development Kit (SDK) nástroj umožňující vývojářům psát a ladit aplikace pro konkrétní prostředí. Z posledních aktuálních dat společnosti Canalys vyplývá, že podíl trhu, který obsazují „chytrá“ mobilní zařízení se neustále zvětšuje. Android zde zabírá až 35% všech prodaných zařízení.

94

SYSTÉMOVÁ INTEGRACE 4/2011

Analýza systému Android ve vztahu ke klientské části informačních systémů

Ilustrace 1: Nárust Adnroid zařízení (http://www.canalys.com/newsroom/androidincreases-smart-phone-market-leadership-35-share) V současnosti je systém Android zastoupen v několika verzích, kde majoritní podíly mají verze 2.1, 2.2 a 2.3 a jejich revize. Jedna z nevýhod tohoto systému je právě dynamičnost, která se projevuje relativně častým vydáváním nových verzí systému a tím i jiných API, které vývojáři používají. To je problém, který je třeba řešit zejména u aplikací, které jsou distribuovány pomocí Android Market a cílí na běžné uživatele. Pro účely tohoto textu a řešenou problematiku je cílení platformy v podstatě dáno již při návrhu systému a volbou cílových hardwarových zařízení se tak zjednodušuje.

3. Zařízení se systémem Android Jak bylo zmíněno Android je jako systém koncipován pro širokou skupinu zařízení. Díky své architektuře je možné jej portovat do různých zařízení, která jsou více či méně vhodná pro tvorbu klienta informačních systémů. Jedním ze základních kritériem, které je nutné brát v úvahu je vstup dat a jejich zobrazení. Realizace je sice možná v zásadě ve všech případech, ovšem ergonomie jednotlivých řešení bude různá. Pokud má být klient koncipován nejen pro zobrazování dat, ale i pro zadávání delších vstupů textu, je vhodnější uvažovat zařízení, které disponuje buď hardwarovou klávesnicí, či má možnost ji připojit. Používání softwarových klávesnic je pro opakované vstupy delších textů nepraktické. Z hlediska zobrazování je problém poněkud jiný, uživatelské rozhraní lze do značné míry přizpůsobit (i dynamicky za běhu) pro různé velikosti displeje na různých zařízeních. Zásadní je pouze schopnost uživatele číst menší písmo na menším displeji, případně použít rolování apod. Důležitým kritériem je dále výdrž na baterie a celkové hw zpracování a odolnost zařízení. Pro případy systému, kde pracovník tráví většinu času v terénu je nutné se


95

Ondřej Berger

zaměřit na zařízení, která možná nepřinášejí například extrémně vysoký výpočetní výkon, ale mají odolnější konstrukci a lepší kapacitu akumulátorů.

3.1 Android jako klient Vzhledem k cílení mobilních zařízení jako prostředků komunikace, které má uživatel neustále s sebou, bude následující analýza a představení systému Android zaměřena na využití v klientské části informačních systemů - při tvorbě klientů IS. Bude tak analyzován jako platforma pro mobilní aplikaci, která má za úkol fungovat jako klient IS a která vzdáleně komunikuje se svým serverem. Budou představeny jednotlivé prvky a komponenty, které lze v takové aplikaci použít a včetně toho jaký mají význam pro klienta (též klientskou část) IS.

3.2 Architektura systému Platforma Android staví nad upraveným operačním systémem Linux. Ve své podstatě lze Android označit za nadstavbu, která je přizpůsobena pro provoz v zařízeních, která disponují skromnějšími prostředky než běžné osobní počítače . Jádro operačního systému je odvozeno od verze 2.6. standardního Linuxového jádra. Změny, které v jádru byly vykonány vývojáři Androidu byly z běžné větve jádra odstraněny, a nyní jsou vyvíjeny nezávisle na původní linuxové větvi. Z pohledu architektonických vrstev je systém členěn do několika základních pater. Nad hardware je standardní vrstva HAL (Hardware Abstraction Layer), která sjednocuje rozhraní k různým hardwarovým komponentám, tak aby další vrstvy architektury mohly využívat jednotné API bez nutnosti specializace podle výrobců. HAL je tak velice úzce integrován přímo s jádrem operačního systému. Vyššími vrstvami nad jádrem jsou jednak nativní systémové knihovny, napsané v jazyce C, které řeší výkonostně náročnější činnosti (typicky grafika, databázová vrstva, šifrování) a dále pak Dalvik Virtual Machine (Dalvik VM) – běhové prostředí pro aplikace. Dalvik VM je obdobou Javovského virtuální stroje. Poskytuje prostředí pro běh aplikací, které jsou interpretovány ze svého bytecode. Aplikace jsou obdobně jako Java programy spouštěny z balíčků obsahujících aplikační třídy a další zdroje. Ve své podstatě tento bytecode vychází z běžných Java class souborů, ovšem s ohledem na odlišné řešení virtual machine a menší výkonnostní možnosti, prochází úpravami a optimalizacemi ještě před vytvořením aplikačního balíčku. Samotná VM je poté navržena tak, aby zároveň mohlo běžet více jejích instancí, které sdílejí určité prostředky.

3.3 Aplikace v systému Aplikace vytvořená pro Android má poněkud odlišný koncept od běžných stolních Java aplikací, dokonce i aplikací pro mobilní verzi Javy v mobilních prostředích J2ME. Každá aplikace, instalovaná do operačního systému získává v Linuxovém prostředí svého unikátního uživatele (unix user) a unikátní skupinu (user group). Tento princip lze přirovnat k víceuživatelskému prostředí osobních počítačů, kdy se k jednomu

96



systému může přihlašovat a pracovat s ním různé množství uživatelů, kteří mají různá práva ke složkám, datům a zařízením. Koncept v Androidu připomíná z tohoto pohledu sandboxovaný model spouštění aplikací. Zde je díky unikátnosti uživatele a skupiny aplikace omezen přístup aplikací do souborového systému (s vyjímkou paměťové karty) pouze do adresáře vyhrazeného příslušné aplikaci. Tohoto je docíleno nastavením unixových práv k adresáři aplikace pouze pro konkrétního uživatele/skupinu. Ostatní uživatelé (=aplikace), do adresáře aplikace přístup nemají a zároveň aplikace nemá přístup nikam jinam. Pouze superuživatel (root), který je v systému díky linuxovému původu také přítomen má práva přistupovat na libovolná místa filesystému a prohlížet/měnit libovolné soubory. Standardně je root přístup povolen pouze v emulátorech, používaných pro vývoj aplikací. K emulátoru je možné se připojit pomocí jednoduchého shellu a pracovat s nimi prakticky stejně jako s jiným linuxovým systémem. Takovýto shell je možné otevřít i do reálného zařízení (například mobilního telefonu), ovšem zde uživatel standardně nemá rootovská práva. (Ta je možné získat pomocí tzv. procesu rootování telefonu, ovšem to je nestandardní zásah do zařízení, který v případě poškození telefonu může být důvodem pro odmítnutí reklamace či opravy. Proto jej dále nebudeme v tomto přehledu uvažovat.) Každá spuštěná aplikace dostane standardně přidělen jeden systémový proces, kterému pak dále odpovídá i jedna instance Dalvik VM. Tedy počet spuštěných aplikací odpovídá počtu běžících VM, které jsou po ukončení procesu aplikace znovupoužity pro nově spouštěné aplikace.

3.3.1 Skladba aplikace Každá aplikace systému Android se může skládat ze čtyř základních komponent, propojených obecným komunikačním prvkem pro zasílání zpráv. V aplikaci se tak mohou nacházet jednotlivé obrazovky zobrazované uživateli, déleběžící procesy obvykle na pozadí systému, posluchače událostí (zpráv) a také poskytovatelé dat pro okolní aplikace. Následně budou představeny stručně tyto komponenty ve vztahu k funkci, kterou mohou zastávat v klientské aplikaci informačního systému. Tedy jakou úlohu mohou sehrát při tvorbě klienta IS. Mimo vlastních komponent a tříd může aplikace samozřejmě využívat i systémové komponenty – například mechanismus pro plánované spouštění činnosti (třída AlarmManager), často využívanou lištu pro zobrazování upozornění (NotificationManager) a mnohé další, jejichž přehled lze nalézt v dokumentaci.

3.4 Komunikace komponent – Intent Výše zmíněný prostředek platformy pro zasílání zpráv reprezentuje tzv. záměr – třída Intent. Tento záměr reprezentuje obecnou akci, která má být vykonána. Pomocí intentů se jednak spouštějí nové obrazovky – aktivity (viz dále), služby, ale i kupříkladu volají externí aplikace. Součástí každého intentu je akce – tedy označení toho co se má provést (zobrazení dat, výběr položky, úprava atp.) a data nad kterými má být akce provedena. Data jsou reprezentována pomocí URI – jedinečného identifikátoru, který má podobný formát jako webová adresa.


97

Ondřej Berger

Tedy například zobrazení seznamu kontaktů v telefonu reprezentuje intent s akcí view a daty content://people. Zde se projevuje i jeden klíčových prvků platformy a to využívání již existujících komponent bez nutnosti psaní vlastních. Pro výše uvedený příklad výběru kontaktu tak není třeba tvořit kód, který načte kontakty z úložiště, zobrazí je a zpracuje výběr. Na základě do systému odeslaného intentu systém sám vybere komponentu, která činnost zrealizuje (včetně případného navrácení výsledku). Tím se značně zjednodušuje návrh aplikace protože je možné využívat již vytvořené komponenty. Takto fungují všechny nepřímé záměry – například k prohlížení webu Univerzity Hradec Králové bude třeba vytvořit intent view s daty http://fim.uhk.cz. Systém vybere všechny komponenty, které jsou registrovány na obsluhu daného intentu na základě jak kombinace akce a dat. Pokud je nalezeno více možných obsluh, je uživateli dáno na výběr, kterou chce použít (například výběr z více webových prohlížečů). Kromě nepřímých intentů, existují i intenty přímé. Ty se využívají zejména uvnitř aplikace samotné například pro spouštění obrazovek či služeb. Zde je intent vytvořen nikoliv na základě akce a dat, ale na základě jména Java třídy, která má být spuštěna. Protože intenty představují komunikační prvek, je nezbytné, aby přenášely i data. Na vždy je ovšem pro vyjádření dat dostačující URI, proto každý intent může nést tzv. extra hodnoty, které dále upřesňují povahu záměru a doplňují informace. Tyto extra hodnoty jsou reprezentovány pomocí hodnotové mapy, tedy dvojic klíč-hodnota. Třída Bundle (hodnotová mapa) umožňuje přenášet v zásadě pouze primitivní datové typy (čísla, řetězce,logické hodnoty). Je sice možné přenášet i hodnoty, které jsou serializovatelné (Java třídy implementující rozhraní Serializable), ovšem není vhodné pomocí intentů přenášet větší objemy dat zejména kvůli rychlosti zpracování. [1]

3.5 Aktivity Aktivita je v pojetí Androidu jedna aplikační obrazovka zobrazená uživateli. Je tedy jedním z klíčových prvků klientské části, protože uživatel se systémem potřebuje komunikovat, číst a zadávat data. Jednotlivé aktivity aplikace jsou na sobě do značné míry nezávislé, ačkoliv se samozřejmě v aplikaci řadí do určitého toku a pořadí, když uživatel mezi nimi přechází. Ovšem je třeba počítat i s možností vyvolání aktivity bez návazností. Například uživatel opustí aplikaci a vrátí se na domovskou obrazovku. Pokud se pak zase navrátí do aplikace, je v případě že nebyla uvolněna z paměti, spuštěna aktivita, kterou měl zobrazenu jako poslední. S tímto je třeba počítat a celý návrh uzpůsobit řešení obrazovek, které fungují v maximální míře samostatně, bez závislosti na ostatních obrazovkách. Řešení při vracení do aplikace je již systémem nastaveno tak, aby si aktivita „pamatovala“ poslední stav (pokud nebyla uvolněna z paměti). Samozřejmě nelze realizovat úplnou nezávislost aktivit – často závisejí například na datech z jiné aktivity, ovšem minimalizací předávaných dat mezi aktivitami a zapouzdřeností lze vytvořit robustní a stabilní aplikaci. Pokud se týká grafických komponent, které lze umístit do aktivit, pak zahrnují v zásadě všechny prvky známé z webu či desktopových aplikací. Lze tedy zobrazovat textové popisky, vstupní pole, výběrové seznamy, seznamy prvků, různé dialogy pro upozornění, či například čekání pro dokončení operace), obrázky a fotografie atp. Z tohoto pohledu je tedy Android standardní prostředí, které má všechny nezbytné 98



součásti. Jediným limitujícím faktorem je velikost a rozlišení displeje, kdy je třeba design aplikace přizpůsobit menšímu rozlišení a velikosti. V případě, že je nezbytné provozovat jednu aplikaci na různých zařízeních, například s různými rozlišeními obrazovky či orientacemi, je možné toho snadno docílit pomocí striktní separace vzhledu od chování. Vzhledy obrazovek jsou obvykle popsány v externích XML souborech. Tyto definice jsou umístěny v adresářích, které pokud dodržují jmenné konvence systému jsou automaticky vybrány na základě hardwarové konfigurace zařízení. Vzhledy je možné odladit přesně pro dané zařízení a jeho obrazovku. Stejně tak funguje i systém při například otočení zařízení na šířku.

3.6 Služby Mimo obrazovky jsou jedněmi z důležitých částí aplikací komponenty pro vykonávání práce na pozadí. V Androidu jsou to komponenty služeb. Zde je třeba zmínit, že služby ačkoliv nemají viditelné GUI, běží ve stejném procesu a také stejném vlákně jako aktivity a zbytek aplikace. Standardně tak nevytvářejí nové vlákno a jejich volání (kupříkladu dlouhotrvající stahování dat či náročný výpočet) blokuje i uživatelské rozhraní – pokud není nové vlákno explicitně vytvořeno. Služby mohou být použity k tomu, aby byly například periodicky spouštěny jednou za daný čas a prováděly synchronizace, stahování apod. v časech kdy aplikace není v popředí. Samozřejmě nelze vyloučit, že služba poběží zároveň s GUI aplikace, a proto by pro veškeré blokující operace měla služba vytvářet nové vlákno (například běžný javovský Thread) a synchronizační třídu Handler. Ta slouží k synchronizovanému informování vláken o událostech a výměně menších datových objemů a zpráv mezi vlákny. Jeden typický scénář použití služeb je kontrola nových emailových zpráv jednou za 30minut. Pomocí systémové komponenty AlarmManager lze vyžádat zaslání intentu za daný časový interval. Na tento intent lze registrovat službu. Ta vytvoří nové vlákno a předá mu synchronizační handler. Vlákno stáhne nové zprávy a pošle data handlerem službě. Služba zkontroluje nové zprávy a kupříkladu zobrazí notifikaci do systémové lišty pro uživatele. Z tohoto pohledu je tedy služba ideální pro činnosti, které nevyžadují zásah uživatele (synchronizace dat) a mohou probíhat bez jeho vědomí. Zároveň je umožněno aby uživatel byl informován například o nových událostech, problémech které nastaly atd. pomocí standardního notifikačního mechanismu.

3.7 Příjemci událostí V některých případech je třeba vhodné klientem pouze reagovat na určité události. K tomuto slouží příjemci událostí (broadcast receivers). Jedná se o jednoduché, úzce specializované komponenty, které jsou zcela pasivní než dojde k události - intentu, na který čekaji. Možnosti těchto posluchačů jsou v porovnání s ostatními komponentami omezené. Obdobně jako služby nemají žádné GUI, a nemohou například vytvořit nové vlákno. Ovšem není problém z nich spustit novou službu, či dokonce aktivitu, které již mají možnosti daleko širší.


99

Ondřej Berger

3.8 Poskytovatelé obsahu Poslední systémovou komponentou jsou tzv. poskytovatelé obsahu (content croviders). Ti jsou určeni ke sdílení dat mezi jednotlivými aplikacemi v celém systému. Poskytují standardizované rozhraní pro přístup k různým zdrojům. Ve zjednodušené podobě se dá říci, že je takto možné sdílet různé entity zpracované pomocí obdobných nástrojů jako nabízí relační databáze. Jak tvorba, tak využívání content providers se v mnoha ohledech (viz [2] – třída ContentProvider) podobá práci s relační databází. Proto jsou často poskytovatelé obsahu tvořeni jako další vrstva přímo nad SQLite relační databází. Při návrhu klienta informačního systému mohou tyto komponenty sloužit k vytvoření datové vrstvy v aplikaci (například pro lokální ukládání dat), případně lze pomocí nich realizovat připojování do zbytku systému. Míra abstrakce je zde poměrně vysoko, a vytvoření content provider se v zásadě omezuje na implementaci příslušného rozhraní. Toto rozhraní umožňuje vkládat data, načítat mazat a dotazovat se na ně. Implementační záležitosti – zda se například ukládaná data serializují do souboru, či ukládají do databáze, nebo dokonce odesílají přes síť na server – zde z hlediska použití nejsou až tak podstatné. Kromě využívání poskytovatelů ve vlastní aplikaci je také možné je nabízet i ostatním aplikacím. Poskytovatel se do systému registruje pomocí unikátní URI, pod kterou je dostupný a poté je možné jej využívat jak z aplikace vlastní, tak cizí. Samozřejmě je možné nastavovat různé úrovně přístupu a oprávnění k provádění operací. Tento mechanismus je použitelný k vytvoření modulárního klienta, který se skládá z více samostatných aplikací, které sdílejí společný datový zdroj – content provider. Správa dat tak může být centralizována a nezasahuje do jiných aplikací, což umožňuje jednodušší vývoj a údržbu takovéto sady aplikací.

4. Srovnání s J2ME Vzhledem k faktu, že syntaxe programovacího jazyka Android vychází z Javy, nabízí se zde srovnání této platformy z pohledu možností a syntaxe, kterou se Android od Javy liší. Protože se pohybujeme v oblasti mobilních technologií, je vhodné toto srovnání provést nad mobilní verzí Javy, tzv. Java Micro Edition (J2ME). Java Micro Edition, jak již její název napovídá, je určena pro vývoj aplikací do miniaturních zařízení, kterými jsou například čipové karty, mobilní telefony či přenosné digitální asistenty PDA. Na základě cílového zařízení (karta, telefon, PDA), se J2ME člení na tzv. konfigurace. Pokud pomineme oblast čipových karet zůstávají dvě základní konfigurace. První z nich Connection Limited Device Configuration (CLDC), je určena do zařízení, která obvykle nedisponují trvalým přístupem k datové síti. V současné době se jedná o velice rozšířené prostředí, které lze nalézt ve většině běžných mobilních telefonů. V závislosti na konkrétním modelu se tato konfigurace vyskytuje doplněná o svůj profil MIDP (nejčastěji ve verzi 2.0 či 2.1) a různé konfigurace volitelných balíčků, které možnosti platformy dále rozšiřují. Tato rozšíření se týkají jak podpory hardware (Bluetooth, GPS apod.), tak i různých technologií (SOAP webové služby, multimédia, šifrování).

100



Druhá konfigurace - Conected Device Configuration (CDC) se nachází povětšinou v zabudovaných zařízeních, jako síťové tiskárny, routery apod., a dále pak ve výkonných mobilních zařízeních PDA či Smartphones. Obecně je tato konfigurace charakteristická trvalým připojením do datové sítě a vyšším výkonem. Svými možnostmi se již blíží standardní Javě v edici SE verze 1.4.2. Vzhledem k faktu, že častěji dostupná je konfigurace CLDC, bude srovnání s Androidem provedeno právě proti CLDC verzi 1.1 a profilu MIDP 2.1.

4.1 Primitivní datové typy Z pohledu možností a primitivních datových typů v obou systémech není v podstatě žádný rozdíl a nabízejí stejnou množinu datových typů, která vychází z platformy Java. Jediný rozdíl byl existoval v konfiguraci J2ME CLDC 1.0, kde není k dispozici číselný typ s plovoucí desetinnou čárkou float.

4.1.1 Kolekce a mapy Z hlediska vývoje (ať už klienta IS či libovolné jiné aplikace) je velice často používaným prvkem jazyka kolekce. Tedy soubor prvků či objektů sdružovaných v rámci jiného objektu. V prostředí J2ME jsou kolekce značně ochuzeny, zastoupena je zde pouze jediná třída z Collection frameworku (CF) a to Vector, který představuje řazený seznam prvků, interně ukládaných v poli. V případě Androidu je již od prvních verzí zastoupena daleko větší část CF a k dispozici jsou jednak obecná rozhraní pro kolekce (java.util.Collection), množiny (Set) či seznamy (List), tak jejich různé implementace (HashSet, ArrayList, LinkedList atd). Z tohoto pohledu je na tom tedy Android lépe, je možné využít konkrétní vhodnou implementaci pro různé potřeby práce s kolekcí. Někdy je vhodné používat například ArrayList pro pouze vkládání a čtení prvků, na druhou stranu, je-li třeba například měnit pořadí prvků, bude efektivnější LinkedList. Ten není backendován polem, ale mezi prvky jsou udržovány reference na další a předchozí prvek. Obdobná je situace i u asociativní polí – map. V případě J2ME je k dispozici pouze třída Hashtable, která je v podstatě mapou. U Androidu je opět celá škála různých implementací rozhraní java.util.Map, které mají různá specializovaná využití opět dle interního řešení dané třídy.

4.1.2 Generické datové typy a syntaxe S ohledem na to, že Android využívá syntaxi jazyka od verze 1.5 (5.0), je zde možné využívat tzv. generické datové typy. Typickým případem využití generik je typizování hodnot v kolekci. Pokud uvážíme prostředí Javy 1.4 a nižší, je možné do kolekce (v případě J2ME tedy do třídy Vector) vkládat libovolné objekty. Ovšem nejčastěji kolecke obsahuje pouze objekty jedné třídy (případně objekty tříd dědících od společného předka). Lze tedy takto deklarovat typovost:

List<User> userList = userService.getAllUsers();


101

Ondřej Berger

Tím je již při překladu zajištěna typovost objektů kolekce a v případě nekompatibility návratové hodnoty a typu proměnné dojde k chybě již při překladu. Zatímco v J2ME je povolená konstrukce pouze:

Vector userList = userservice.getAllUsers(); Je tak možné, že například chybou budou metoda vracet objekty jiné třídy než očekáváme dále v kódu. Z tohoto pohledu je tedy přítomnost generických typů v Androidu výhodou i z hlediska tvorby API komunikujícího s nějakým systémem. Je možné jasně definovat jak na serveru, tak v klientu přesné rozhraní a eliminovat tak část možných chyb.

4.1.3 Bytecode V souvislosti se syntaktickými rozdíly mezi verzemi Javy 1.4 a 5.0 se samozřejmě liší i verze překládaných souborů obsahujících bytecode pro VM. Ovšem v případě Androidu slouží tyto class soubory pouze jako mezistupeň, protože jsou dále překládány do formátu dex, který využívá Dalvik VM. Tyto dex soubory oproti původním Java class souborům procházejí procesem optimalizací a úprav pro virtuální stroj Dalvik.

4.2 Konektivita Důležitým prvkem pro spojení mobilního klienta se zbytkem systému je přítomnost řešení pro komunikaci. Jedná se nejprve o řešení na fyzické úrovni, tedy vhodná, nejčastěji bezdrátová komunikace s datovou sítí. Pokud uvažujeme rozšíření systému Android v různých zařízeních, je často přítomno připojení přes mobilní sítě (GSM/EDGE, 3G), které má v závislosti na operátorovi různé úrovně pokrytí a kvality služeb, tak i připojení přes poměrně rozšířené bezdrátové sítě Wi-Fi. Ty sice zdaleka nemají pokrytí jako mobilní sítě, ovšem i tak lze nalézt širokou řadu bezplatných přípojných míst (hotspotů). Pro zhodnocení systému Android ovšem není třeba zabývat se technologickým řešením komunikace – v zásadě stačí rozlišovat pouze stavy „připojen“ a „odpojen“ od datové sítě bez ohledu na technologii připojení. V bližším pohledu je třeba samozřejmě druh připojení uvažovat a to zejména z hlediska přenosové rychlosti. Při návrhu je třeba vždy počítat s horším scénářem v podobě pomalého připojení a eventuelně i ztráty připojení v průběhu komunikace. Hledisko rychlosti lze řešit zejména pomocí minimalizace přenášených dat (pouze nezbytná data, komprese, postupné přenášení až v případě potřeby atp.) a volbou vhodného formátu. Je vhodnější zde upřednostnit binární protokoly, které minimalizují přenášená režijní data. Naproti tomu XML-based formáty bývají obecně náročnější na přenášená data a také i rychlost zpracování. Zajímavou alternativou komunikace může být architektonický návrh REST. Representational State Transfer je řešení založené ve většině případů na již existujících technologiích. Tato architektura obecně pracuje se zdroji, a 4 základními operacemi. Pojem zdroje je velice obecný, v zásadě jím může být cokoliv, od entity (kniha v knihovně) až po stav systému (například teplota v místnosti). Každý zdroj má svoji adresu, a lze s ním provést pouze 4 základní operace v podobě vytvoření, změny, získání a smazání (viz kap.5 v [3]). Pro tyto operace je třeba zdroj vyjádřit ve formě vhodné reprezentace, což je poslední základní pojem z REST architektury. 102



Reprezentace je vyjádření zdroje, například entita knihy popsaná pomocí informací ve formátu XML. Ovšem jeden zdroj může mít více reprezentací, takže u zmíněné knihy může být dále i obrázková reprezentace představující obálku ve formátu JPG. Z detailního pohledu na REST architekturu vyplývá, že nabízí vhodné řešení pro tvorbu komunikačního rozhraní pro mobilní klienty. Architektura se velice často zakládá na http protokolu, který nabízí řešení pro všechny základní pojmy – adresaci z zdroje v podobě URL, operace se zdrojem v podobě metod http (GET, POST, PUT, DELETE) a přenos různých reprezentací. Přínosnější tuto architekturu dělá skutečnost, že REST rozhraní nemusí být nutně orientováno pouze na mobilní klienty, ale lze je využít jako obecné rozhraní pro komunikaci dalších (i nemobilních) klientů a systémů. Při zachování stejných operací a zdrojů, lze například pro klienty v podobě PC přinášet XML reprezentaci, pro mobilní klienty například úspornější Hessian či JSON. Pokud jde o podporu protokolu http, je z hlediska realizace možné využívat podmnožinu API, kterou poskytuje knihovna Apache Http Client a která je částí API platformy Androd. Toto API umožňuje práci s http protokolem a spojeními.

4.2.1 Datové formáty Nad vrstvou spojení http je možné realizovat různé metody dotazů a předávání dat. V případě metod posílajících data (PUT, POST) jsou data i v odchozím požadavku zasílaném na server. Příchozí data jsou potom obvykle součástí příchozí zprávy, odkud se dají získat obdržet jako stream. Formát, ve kterém jsou data v entitě zapouzdřena může být v zásadě libovolný a je nutné jej správně zpracovat.

XML Častý datový formát využívaný v prostředí sítí a Internetu je XML. Tento značkovací jazyk má široké možnosti v oblasti vyjádření různých dat. V systému Android jsou k dispozici různé způsoby zpracování XML souborů: • SAX – Simple API for XML, je založeno na sekvenčním procházení dokumentu a zpracování událostí na jednotlivých elementech. •

Pull XML parser – obdobné předchozímu SAXu, ovšem události jsou vyvolávány parsovacím mechanismem.

•

DOM – Document Object Model je založen na načtení celého XML do paměti a vytvoření objektové reprezentace celého stromu.

Jednotlivé přístupy pro parsování XML mají své výhody a nevýhody. První dva jsou poněkud náročnější na algoritmizaci, ovšem mají daleko nižší paměťové nároky a jsou v porovnání s DOM modelem rychlejší. Na druhou stranu DOM má přímočařejší API a snažší zpracování, ovšem daní za to je velikost zabrané paměti. To v prostředí mobilních zařízení představuje zásadní nevýhodu.

JSON Oproti XML existuje jednoduchý formát JSON – Java Script Object Notation, který má široké využití v oblasti webových technologií. Jedná se o textový formát, který umožňuje přenášet i komplexní datové struktury obdobně jako XML, ovšem s nižšími nároky jak na velikost přenášených dat, tak i paměťového zpracování. Jeho nevýhodou je nemožnost serializovat grafy, tj. cyklické závislosti mezi objekty, kdy se SYSTÉMOVÁ INTEGRACE 4/2011

103

Ondřej Berger

objekty navzájem odkazují. Lze serializovat pouze strom, tedy závislost ve smyslu kdy objekt obsahuje jiné objekty. [4] V systému Android je přítomen port referenční knihovny JSON, který umožňuje zpracovávat příchozí data i data do formátu JSON naopak serializovat (například pro odchozí zprávy do systému). S ohledem na svoje vlastnosti představuje JSON vhodný transportní formát pro přenos dat mezi klientem a systémem.

Hessian Protokol Hessian od společnosti Caucho je binární alternativou k výše uvedeným protokolům. Hessian lze použít pro serializaci dat, ovšem primárně je navržen jako kompletní protokol pro RPC volání mezi různými platformami. Nabízí řešení vystavení metod na serveru a jejich volání klientem. Ovšem kupříkladu pro REST architektury jej lze použít čistě pro binární serializaci, kdy se nevyužívá část pro řízení RPC, ale pouze binární datová reprezentace.

4.2.2 Webové služby Komplexní řešení komunikace představují webové služby. V prostředí systému Android neexistuje standardně dostupná implementace tohoto standardu, jak ji definuje například JSR-172 pro Java Micro Edition. Používaný je proto neoficiální port knihovny kSOAP2 [5] do prostředí Android. Portování této knihovny bylo dle dokumentace v zásadě vytvořením implementace transportní třídy – ostatní třídy jsou díky značné kompatibilitě mezi prostředím J2ME a Androidu pouze minimálně upraveny. Proto princip práce s touto knihovnou zůstává stejný a relativně složitý, a je nastíněn například v [6].

5. Využívání kontextu Kromě jednotlivých komunikačních řešení, je v současnosti aktuální využívání tzv. kontextových informací. Následující část text přiblíží tyto údaje a způsob jejich zpracování na platformě Android.

5.1 Kontext Žádná akce v našem prostředí se neodehrává ve vzduchoprázdnu, vždy se vyskytují okolnosti, které se na průběhu činnosti mohou podílet. Díky tomu se kolem každé akce vyskytuje velké možství dat a údajů, které mohou být využity nejen k zaznamenání či zobrazení, ale i k hlubší podpoře aktérů. Tyto okolní skutečnosti lze popsat pojmem kontext. Kontext tak můžeme definovat jako „množinu faktů a okolností, které obklopují událost či situaci“(z [7]). Z této definice mj. vyplývá i to, že pojem kontext je velice obecná záležitost, kterou lze vztáhnout na mnoho oblastí lidské činnosti včetně lingvistiky, historie ale také třeba medicíny. Pojem kontextu v IT definuje již několik autorů, např. Dey a Abowd ([8]) kontext popisují jako „informaci použitelnou k charakterizaci situace entity (místa, osoby), jež je považována za důležitou ve vztahu mezi uživatelem a aplikací“. Pro potřeby dalšího textu tato definice poskytuje podstatnou myšlenku – a to je vztah mezi informací a 104



činností. Podobně pak kontext definují i další autoři, Chen a Kotz kontext popisují jako „množinu stavů prostředí, které podmiňují chování aplikace nebo ve kterém se odehrává aplikační událost, a jenž jsou zajímavé pro uživatele“ ([9]). Shrnutím předchozích definic a aplikací do mobilních technologií dostáváme stav, kdy aplikace využívá senzory zařízení, na kterém je spuštěna a zaznamenává a využívá tyto údaje ke své činnosti. Tento způsob ovlivnění aplikace v závislosti na údajích okolí se v angličtině nazývá „context-awarennes“ - povědomí o kontextu.

5.1.1 Poloha Bezesporu jedním z kontextových údajů, který nachází široké využití je poloha. Aplikace využívající polohu klienta se zahrnují do skupiny tzv. Location Based Services - služby založené na poloze. Toho se nechá využívat například při navigování uživatele k cíli cesty nebo pro informování o blízkých zájmových objektech – u klienta IS pro obchodního cestujícího to mohou být zákazníci, které má navštívit apod. Ve většině zařízení platformy Android je možné polohu ze senzoru obdržet. V praxi se využívají dvě metody - zaměření podle GSM sítě a zaměření podle signálu GPS.Obecně platí, že si aplikace od systému vyžádá poskytovatele polohy (službou LocationManager) a tohoto poskytovatele pak požádá o polohu, která je reprezentována třídou Location. Podle poskytovatele polohy se samozřejmě liší i přesnost poskytované polohy a tím i využití pro různé aplikace. V případě signálu GPS lze dosáhnout přesnosti řádově jednotek metrů, zatímco zaměření přes GSM sítě může mít chybu v řádech kilometrů. U získávání polohy lze postupovat několika způsoby – lze vyžádat poslední známou polohu od příslušného poskytovatele, případně požádat poskytovatele aby v určitých definovaných podmínkách informoval aplikaci o změně polohy. Tato notifikace může být založena buď na změně o určitou vzdálenost v metrech, případně po uplynutí časového intervalu. K tomuto účelu slouží rozhraní LocationListener, které umožňuje obsluhu změn polohy. Případně lze využívat tzv. ProximityAlert, který slouží k upozornění v případě přiblížení se k definovaným souřadnicím. Výše uvedené způsoby využití polohy mohou najít uplatnění v aplikacích, které vyžadují práci v terénu. Například servisní technici, kteří vyjíždějí ze základny k zásahu mohou mít klientskou aplikaci, která z informačního systému obdrží kromě informací o zásahu (druh práce, priorita apod.) i polohu, kterou spolu může klient IS využít k navigování na místo zásahu.

5.1.2 Orientace zařízení v prostoru Spolu s polohou je v některých aplikacích LBS – například v tzv. augmented reality, nutné zjistit kromě polohy i orientaci zařízení v prostoru – tedy náklon v prostorových osách a orientaci dle světových stran. V systému Android existuje obecná reprezentace senzorových dat, s obdobným způsobem jako u polohy je zde systémová služba SensorManager, která poskytuje přístup k různým senzorům, kterými zařízení disponuje. Je tedy možné pracovat jak s elektromagnetickým kompasem, který určuje orientaci dle světových stran, tak i gyroskop a akcelerometr, které poskytují informace


105

Ondřej Berger

o náklonu, případně zrychlení v jednotlivých osách. Údaje přímo v „surové“ podobě ze senzorů lze získat pomocí třídy Sensor, vyžádané ze SensorManageru.

5.1.3 Obraz kamery Jedním z důležitých okolních kontextů lze spatřit ve vizuálním obrazu okolí získaném prostřednictvím kamery/fotoaparátu. V současnosti je ovšem strojové zpracování obrazu ve smyslu rozpoznání a identifikování objektů stále v plenkách, jak v mobilních zařízeních tak i běžných počítačích. Mimo oblast rozpoznávání scény má obraz kamery v současnosti velice vhodné využití jako „plátno“ do kterého se promítají dodatečné informace, tzv. augmented reality. V tomto využití je pouze snímán obraz kamery a před zobrazením uživateli na displeji je do obrazu na základě údajů z dalších senzorů (poloha a orientace) a vhodných databází zapracována vrstva dodatečných informací. Ve zmiňovaném případě servisního zásahu je tak možné do obrazu z kamery zakomponovat detaily o plánované činnosti a umožnit tak rychlou orientaci v terénu.

6. Zhodnocení Tento text byl zaměřen na „rozebrání“ platformy na jednotlivé části a jejich zhodnocení a možné využití při vývoji mobilní klientské části IS. K tomu je třeba zhodnotit nejen technické, ale také ekonomické aspekty platformy a uvést je do souvislosti s požadavky na klienta.

6.1 Ekonomické aspekty Při ekonomickém hodnocení platformy je jedním z klíčových poznatků fakt, že celá platforma je postavená jako opensource. Tedy je k ní k dispozici zdrojový kód, a je možné jej využívat. Dále existuje referenční dokumentace ([2]) a poměrně bohaté materiály ve formě diskuzních fór a článků, které umožňují efektivní řešení problémů při vývoji. Dalším nezanedbatelným aspektem je fakt, že na rozdíl od jiných mobilních platforem není Android při vývoji vázán na konkrétní operační systém (vývojové prostředí je dostupné pro všechny majoritní platformy Linux, Mac i Windows) a nástroje spolu s SDK (Software Development Kit) jsou k dispozici zdarma a staví na zdarma dostupných a kvalitních produktech jako je například platforma Eclipse.

6.2 Technologické aspekty Platforma nabízí moderní API stavící na základu jazyka Java, včetně generických typů, známých od verze JSE 5.0. Z technologické hlediska řešení systému je pak neméně důležitá komunikace klienta a serveru, což je nutné pokládat za klíčovou funkcionalitu. V Androidu je zastoupena implementace protokolu HTTP, který je využíván jako časté transportní řešení, nad kterým je možné využívat různé datové formáty. S využitím vhodných knihoven je možné komunikovat se SOAP webovými službami, či využívat REST rozhraní, které umožňuje realizovat úspornější komunikaci například v datových formátech a protokolech Hessian či JSON. Kromě komunikace, která je sice důležitým prvkem,ale ne jediným, je dále možné navrhovat grafická rozhraní aplikace přesně na míru cílovým zařízením. Toho je 106



možné docílit oddělením vzhledu aplikace od kódu a zároveň přitom zanechat přenositelnost mezi různým hardware. Knihovna rozhraní umožňuje používat širokou škálu prvků a komponent, které postačují k vytvoření funkční i přehledné aplikace pro různé účely. Po designu a komunikaci, jsou další systémové komponenty již „volitelné“ ve smyslu, že záleží na konkrétní problematické doméně, zda budou využity, či nikoliv. Jedná se třídy a prvky, které umožňují klientské aplikaci reagovat na různé události a kontexty (přístup k síti, stav baterie, senzory, poloha) a zpracovávat jejich změny. Stejně tak další komponenty, služby, které umožňují provádět operace na pozadí, během jiné činnosti uživatele, mohou ale nemusí být využívány. S nimi je možné realizovat častou funkcionalitu automatických synchronizací dat, práce na pozadí aplikace/systému či automatických aktualizací bez nutnosti zásahu uživatele. Z pohledu technologií tak představuje Android v mobilní oblasti prostředí, ve kterém je možné realizovat v zásadě libovolný záměr při mobilním vývoji.

7. Závěr Článek představuje možnosti platformy Android a jednotlivé poznatky při využití této platformy pro vývoj klienta informačních systémů. Jedná se o jednu z rychle se vyvíjejících se platforem, která je cílena na různé druhy mobilních zařízení od mobilních telefonů a tabletů až po netbooky. Tato rozmanitost nabízí využít klientskou aplikaci v různých prostředích na základě požadavků a přitom využívat již jednou nabyté znalosti a zkušenosti při vývoji dalších aplikací. V textu je představena platforma a její jednotlivé možnosti ve vztahu při tvorbě informačního systému. Z jednotlivých komponent, které jsou použitelné v tvorbě klientských aplikací vyplývá, že pokrývají většinu požadavků, které jsou na aplikace kladeny. Od různých forem zobrazení, až po řešení periodicky volaných činností, zpracování úloh na pozadí či využívání senzorů a kontextových informací. Ze závěrečného srovnání vyplývá, že Android jako platforma je novou alternativou pro vývoj mobilního klienta. Nástroje a dokumentace jsou k dispozici zdarma a existuje poměrně široká, dále se rozrůstající vývojářská komunita. To z Androidu činí konkurenci k existujícím platformám a přináší i nezanedbatelnou výhodu při samotné realizaci aplikace.

Zdroje [1] Android Developers [online]. 2008 [cit. 2011-08-23]. Intent's Extra transfer. Dostupné z WWW: . [2] Android [online]. 2009 [cit. 2011-08-23]. Android Reference Documentation. Dostupné z WWW: . [3] FIELDING, R.: Architectural Styles and the Design of Network-based Software Architectures. [s.l.], 2000. 180 s. Dizertační práce. Dostupný z WWW: . [4] Caucho Technology [online]. 2011 [cit. 2011-08-23]. Metaprotocol Taxonomy. Dostupné z WWW: .


107

Ondřej Berger

[5] KSOAP2 [online]. 2006 , 2006-10-23 [cit. 2009-02-03]. Dostupný z WWW: . [6] BERGER, O.:. Integrace mobilního klienta do IS přes webovou službu. Systémová integrace [online]. 2010, 4, Dostupný z WWW: . ISSN 1804-2716. [7] WordNet [online]. 2011, 2011 [cit. 2011-08-23]. WordNet Search. Dostupné z WWW: . [8] DEY, A.K.; ABOWD, G.D.: Towards a Better Understanding of context and contextawarennes. In . In HUC ’99: Proceedings of the 1st international symposium on Handheld and Ubiquitous Computing : Springer-Verlag, 1999. s. 304-307. Dostupné z WWW: . [9] CHEN, G., KOTZ, D.: A Survey of Context-Aware Mobile Computing Research. In Technical Report: TR2000-381 . Hannover : Dartmouth College, 2000. s. 381. Dostupné z WWW: .

108


Analýza systému Android ve vztahu ke klientské části informačních systémů

Recommend Documents