1 Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky Diplomová práce Polymorfní aplikace pro systém Andr...
Za´padoˇceska´ univerzita v Plzni Fakulta aplikovany´ch vˇed Katedra informatiky a vy´poˇcetn´ı techniky
Diplomov´ a pr´ ace Polymorfn´ı aplikace pro syst´ em Android
Plzeˇ n 2013
Bc. Milan Staffa
Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou pr´aci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 12. kvˇetna 2013 Bc. Milan Staffa
Abstract This thesis deals with the creation of polymorphic application for Android OS, which will change its behavior and graphical user interface according to set rules. The goal of this work is to explore the possibility of local and remote code execution on the Android platform and its use in the polymorphic application. The next task is to create XML rules for this application. The polymorphic application must be made with regard to security. The applicability of the final polymorphic application is tested on a set of generated applications.
Obsah Podˇ ekov´ an´ı
1
´ 1 Uvod
2
2 Polymorfn´ı aplikace
4
3 Pˇ redpis chov´ an´ı a podoby polymorfn´ı aplikace
Podˇ ekov´ an´ı R´ad bych podˇekoval Ing. Ladislavu Peˇsiˇckovi za veden´ı a cenn´e rady pˇri vytv´aˇren´ı t´eto diplomov´e pr´ace.
1
´ 1 Uvod Diplomov´a pr´ace se vˇenuje problematice tvorby polymorfn´ı aplikace pro mobiln´ı zaˇr´ızen´ı s operaˇcn´ım syst´emem Android. Operaˇcn´ı syst´em Android se v dneˇsn´ı dobˇe st´av´a jedn´ım z nejpopul´arnˇejˇs´ıch a nejrozˇs´ıˇrenˇejˇs´ıch operaˇcn´ıch syst´em˚ u na trhu s mobiln´ımi zaˇr´ızen´ımi. D´ıky tomu se objevuj´ı nov´e moˇznosti jeho pouˇzit´ı pro tvorbu aplikac´ı s moˇznost´ı jejich rozˇs´ıˇren´ı do praktick´eho vyuˇzit´ı. Mobiln´ı zaˇr´ızen´ı jsou dnes i pˇres rychl´ y v´ yvoj st´ale ˇcasto pomˇernˇe nev´ ykonn´e (v˚ uˇci napˇr. notebook˚ um, stoln´ım poˇc´ıtaˇc˚ um, server˚ um a dalˇs´ım zaˇr´ızen´ım) a je proto nutn´e u vytv´aˇren´ ych aplikac´ı br´at ohled na v´ ykonnostn´ı n´aroky aplikac´ı. Nˇekter´a zaˇr´ızen´ı jsou limitov´ana napˇr. velikost´ı operaˇcn´ı pamˇeti (kter´a je u mobiln´ıch zaˇr´ızen´ı ˇcasto pomˇernˇe omezena) a v´ ykonem procesoru. Dalˇs´ım omezen´ım je vysok´a spotˇreba energie pˇri vykon´av´an´ı sloˇzitˇejˇs´ıch operac´ı s neˇza´douc´ım vlivem na vyb´ıjen´ı baterie. Standardn´ı mobiln´ı aplikace m´a pˇresnˇe ud´ano sv´e chov´an´ı a grafickou podobu. Tato podoba a chov´an´ı aplikace byla vytvoˇrena v´ yvoj´aˇrem. Jedna aplikace tak pln´ı svou pˇredem udanou u ´lohu. V pˇr´ıpadˇe, ˇze uˇzivatel potˇrebuje prov´est jin´ yu ´kon ˇci prov´adˇet jin´e u ´lohy, pro kter´e dan´a aplikace nebyla naprogramov´ana, mus´ı k tomu vyuˇz´ıt jinou aplikaci. Takovou aplikaci mus´ı nˇekdo naprogramovat a publikovat. Uˇzivatel si ji pak mus´ı st´ahnout a nainstalovat. To je d˚ uvod, proˇc je vhodn´e vyuˇz´ıt jedn´e aplikace, kter´a z´ısk´a po pˇred´an´ı nˇejak´eho pˇredpisu jinou podobu a chov´an´ı. Aplikace, kter´a m´a tyto vlastnosti se naz´ yv´a polymorfn´ı aplikac´ı“. Polymorfn´ı aplikace m´a ” oproti standardn´ı aplikaci v´ yhodu. Ta spoˇc´ıv´a v tom, ˇze aplikaci staˇc´ı jednou nainstalovat a pak lze mˇenit podobu a chov´an´ı polymorfn´ı aplikace pouze t´ım, ˇze j´ı pˇred´ame adresu pˇredpisu definuj´ıc´ı tyto vlastnosti. Dalˇs´ı v´ yhoda, kter´a lze vyuˇz´ıt u polymorfn´ı aplikace, je pak zpracov´av´an´ı operac´ı na vzd´alen´em zaˇr´ızen´ı. N´aroˇcn´e operace lze zpracov´avat na jin´em zaˇr´ızen´ı a t´ım sn´ıˇzit ˇcas jejich prov´adˇen´ı. S t´ım jsou tak´e spojen´e menˇs´ı n´aroky na v´ ykonnost mobiln´ıho zaˇr´ızen´ı, protoˇze se z´atˇeˇz na proveden´ı u ´lohy pˇrenese na vzd´alen´e zaˇr´ızen´ı. Obecnˇe m´a polymorfn´ı aplikace d´ano sv´e chov´an´ı urˇcit´ ym pˇredpisem. Dle tohoto pˇredpisu se m˚ uˇze zmˇenit jak uˇzivatelsk´e rozhran´ı dan´e aplikace, tak i jej´ı funkˇcnost. Proto vyvst´av´a ot´azka, zda za urˇcit´ ych okolnost´ı nen´ı vhodnˇejˇs´ı pro v´ yvoj´aˇre aplikac´ı vytv´aˇret polymorfn´ı aplikace, kter´e se mohou chovat dle zadan´eho pˇredpisu, n´aroˇcnˇejˇs´ı v´ ypoˇcty se budou prov´adˇet vzd´alenˇe a z d˚ uvodu u ´spory pamˇeti si 2
´ Uvod stahovat pouze ˇca´sti k´odu, kter´e potˇrebuj´ı pro svou ˇcinnost. C´ılem t´eto diplomov´e pr´ace je prozkoumat moˇznosti tvorby takov´eto polymorfn´ı aplikace a navrhnout specifikaci pˇredpisu, dle kter´e se bude urˇcovat podoba a chov´an´ı t´eto aplikace. Pomoc´ı toho tak´e dos´ahnout popisu pro v´ yvoj´aˇre, jak pro tuto aplikaci vytv´aˇret ˇsirokou ˇsk´alu r˚ uzn´ ych generovan´ ych aplikac´ı“, funguj´ıc´ıch s podporou t´eto ” polymorfn´ı aplikace. Dalˇs´ım u ´kolem pr´ace je uk´azat na vytvoˇren´ ych vzorov´ ych aplikac´ı spr´avnost a pouˇzitelnost tohoto n´avrhu a jeho ˇsirok´e moˇznosti.
3
2 Polymorfn´ı aplikace Pro pˇredstavu toho, co je u ´kolem t´eto pr´ace je potˇreba vysvˇetlit pojem polymorfn´ı ” aplikace“. Vˇetˇsina aplikac´ı, kter´e se pro mobiln´ı operaˇcn´ı syst´em Android pouˇz´ıvaj´ı, se chov´a dle toho, jak je p˚ uvodn´ı program´ator naprogramoval. Jde tedy o to, ˇze aplikace m´a jiˇz od sv´eho vzniku pˇresnˇe d´ano, jak se m´a chovat a jakou podobu m´a m´ıt jej´ı grafick´e uˇzivatelsk´e rozhran´ı. Polymorfn´ı aplikace jsou zaloˇzeny na principu, ˇze funguj´ı jako jeden program, kter´ y dle z´ıskan´eho pˇredpisu m˚ uˇze napodobovat nebo pˇrevz´ıt chov´an´ı s r˚ uznou funkˇcnost´ı. Jedna aplikace tak m˚ uˇze simulovat v´ıce aplikac´ı, kter´e by jinak bylo nutn´e vytvoˇrit samostatnˇe. Tento princip poskytuje ˇradu v´ yhod. Jednou z v´ yhod je to, ˇze pro mobiln´ı zaˇr´ızen´ı je ˇcasto limituj´ıc´ım faktorem velikost vnitˇrn´ı pamˇeti a nen´ı tak moˇzn´e m´ıt vˇzdy vˇsechny potˇrebn´e aplikace na jednom mobiln´ım zaˇr´ızen´ı. Proto se d´a vyuˇz´ıt toho, ˇze veˇsker´a potˇrebn´a funkˇcnost je z´ısk´av´ana aˇz dle potˇreby. Dalˇs´ı v´ yhoda vypl´ yv´a napˇr. z pouˇzit´ı v r˚ uzn´ ych organizac´ıch a firm´ach. Jde o to, ˇze firmy mohou na mobiln´ı zaˇr´ızen´ı sv´ ym zamˇestnanc˚ um nahr´at jednu aplikaci a dle potˇreby ˇci funkce zamˇestnanc˚ u jim d´at k dispozici pouze funkˇcnosti, kter´e pro svou pr´aci potˇrebuj´ı. Takov´ato aplikace by tedy mohla m´ıt velk´e vyuˇzit´ı jak pro v´ yvoj´aˇre, tak i pro zjednoduˇsen´ı pr´ace v mnoha odvˇetv´ıch. V r´amci urˇcit´ ych projekt˚ u dnes vznikaj´ı obdobn´e aplikace, kter´e vˇsak myˇslenku polymorfismu zpracov´avaj´ı r˚ uzn´ ym zp˚ usobem. Mezi nejrozˇs´ıˇrenˇejˇs´ı typ patˇr´ı aplikace, jejichˇz c´ılem nen´ı m´ıt r˚ uzn´a chov´an´ı jedn´e aplikace, ale moˇznost, aby jedna aplikace mohla b´ yt spuˇstˇena na r˚ uzn´ ych platform´ach. Tato problematika je zaloˇzena na myˇslence, ˇze nˇekter´e aplikace, kter´e vzniknou pro napˇr. mobiln´ı operaˇcn´ı syst´em iOS, nejsou dostupn´e pro platformy Android, Windows Phone a dalˇs´ı. Proto se hled´a zp˚ usob, kter´ ym by bylo moˇzn´e vytvoˇrit v r´amci v´ yvoje jednu danou aplikaci, kterou lze provozovat na r˚ uzn´ ych mobiln´ıch zaˇr´ızen´ıch (respektive r˚ uzn´ ych mobiln´ıch operaˇcn´ıch syst´emech) bez u ´prav nebo cel´eho nov´eho“ v´ yvoje aplikace. ” Uveden´a problematika byla napˇr´ıklad prob´ır´ana v r´amci prezentace One CODE ” to rule them all“ na konferenci Apps World roku 2011 v Cape Town (Jihoafrick´a republika). V´ıce informac´ı o t´eto prezentaci a jej´ıch v´ ysledc´ıch v [Lin11].
4
Polymorfn´ı aplikace
T´ımto principem se napˇr´ıklad zab´ yvaj´ı projekty PhoneGap (viz [Pho13]), Rhomobile (viz [Mot13]), RAMP (viz [Vir10]), Appcelerator Titanium (viz [App13]) a J2ME Polish (viz [Eno13]), kter´e jsou v [Lin11] t´eˇz zm´ınˇeny. Dalˇs´ım moˇzn´ ym pˇr´ıstupem se zab´ yvalo jedno ze setk´an´ı v r´amci sady konferenc´ı La Degustation Online“. Na tomto setk´an´ı se prob´ırala moˇznost, zda nen´ı m´ısto po” uˇzit´ı nativn´ıch aplikac´ı (tedy takov´ ych, kter´e jsou vytvoˇreny pouze pro jednu danou platformu) ˇci hybridn´ıch aplikac´ı (ty dok´aˇz´ı vyuˇz´ıt hardwarov´ ych schopnost´ı telefonu a z´aroveˇ n jsou pouˇziteln´e na v´ıce platform´ach, mus´ı vˇsak b´ yt nicm´enˇe online) lepˇs´ı pouˇz´ıt mobiln´ı web. Mobiln´ı web je podle v´ ysledk˚ u tohoto setk´an´ı nejuniverz´alnˇejˇs´ı formou, kter´a je funkˇcn´ı napˇr´ıˇc platformami. Jedn´a se o podobu str´anek, jeˇz by mˇela b´ yt pˇrizp˚ usobena omezen´ım mobiln´ıho prohl´ıˇzeˇce i mal´ ych obrazovek telefon˚ u. Uˇzivatelsk´a pˇr´ıvˇetivost je pochopitelnˇe z´avisl´a na rychlosti pˇripojen´ı, kter´a se liˇs´ı dle lokality, poskytovatele, druhu datov´eho tarifu atd. Z´asadn´ı nev´ yhoda vˇsak vypl´ yv´a z nutnosti st´al´eho online pˇripojen´ı k spr´avn´e funkˇcnosti a velmi omezen´e funkˇcnosti, kterou lze vyuˇz´ıt pro pr´aci s mobiln´ım telefonem. V´ıce o tomto setk´an´ı v [Mic11]. V minul´ ych letech vznikla na Z´apadoˇcesk´e univerzitˇe v Plzni bakal´aˇrsk´e pr´ace na t´ema Dynamick´a tvorba aplikac´ı v syst´emu Android“ (viz [Hul12]). V t´eto pr´aci ” se jej´ı autor zab´ yval problematikou toho, zda je moˇzno vytvoˇrit za bˇehu aplikace jej´ı uˇzivatelsk´e rozhran´ı. Myˇslenka o vytvoˇren´ı aplikace pro mobiln´ı operaˇcn´ı syst´em Android, chovaj´ıc´ı se dle nˇejak´eho pˇredpisu, byla z´akladn´ı pro tuto diplomovou pr´aci zab´ yvaj´ıc´ı se tvorbou polymorfn´ı aplikace. Ve zm´ınˇen´e bakal´aˇrsk´e pr´aci vˇsak byla navrˇzen´a a vytvoˇren´a mobiln´ı aplikace svou funkˇcnost´ı velmi omezen´a a z hlediska polymorfismu patˇrila sp´ıˇse mezi standardn´ı aplikace, u nichˇz je chov´an´ı pˇresnˇe ud´ano dopˇredu.
5
3 Pˇredpis chov´an´ı a podoby polymorfn´ı aplikace Pro vytvoˇren´ı polymorfn´ı aplikace je nejprve nutno urˇcit, jak´ ym zp˚ usobem aplikaci sdˇelit, jak se m´a aplikace chovat (respektive jakou ˇcinnost m´a aplikace prov´adˇet) a jak m´a vypadat (jinak ˇreˇceno, urˇcit rozloˇzen´ı a podobu ovl´adac´ıch prvk˚ u grafick´eho uˇzivatelsk´eho rozhran´ı aplikace). K tomuto u ´ˇcelu se d´a napˇr´ıklad vyuˇz´ıt extern´ıho k´odu, kter´ y bude chov´an´ı a podobu aplikace pˇredepisovat. Tento k´od m˚ uˇze b´ yt uloˇzen na s´ıti (respektive na serveru) a z n´ı ho m˚ uˇze polymorfn´ı aplikace z´ıskat pro dynamick´e vygenerov´an´ı sv´eho grafick´eho uˇzivatelsk´eho rozhran´ı. Pro vytvoˇren´ı grafick´eho uˇzivatelsk´eho rozhran´ı mobiln´ı aplikace (tedy definov´an´ı podoby uˇzivatelsk´eho rozhran´ı mobiln´ı aplikace) je tˇreba nadefinovat, jak´e objekty se maj´ı v tomto rozhran´ı vyskytovat, kde se maj´ı vyskytovat a pˇredepsat jim jejich chov´an´ı. K takov´emu popisu se nejv´ıce hod´ı Extensible Markup Language“ (ne” boli XML), jehoˇz z´akladn´ı vlastnost´ı je jeho pˇresnˇe udan´a specifikace. Ta se obecnˇe vyuˇz´ıv´a napˇr´ıklad pro v´ ymˇenu dat mezi aplikacemi. Dalˇs´ı v´ yhodou XML je jednoduch´a ˇcitelnost a pˇrehlednost pr´ace s t´ımto typem popisu (respektive typem souboru obsahuj´ıc´ı form´at dat dan´ y touto specifikac´ı). Pomoc´ı XML lze tedy snadno popsat, jak m´a aplikace vypadat. V´ yvoj´aˇr˚ um se nab´ız´ı moˇznost XML dokumenty doplˇ novat tak, aby si sami dotvoˇrili podobu aplikace dle sv´ ych pˇredstav a poˇzadavk˚ u. V pˇr´ıpadˇe tvorby form-based“ (respektive formul´aˇrov´e) aplikace staˇc´ı z kolekce ” moˇzn´ ych objekt˚ u v´ yvojov´eho prostˇred´ı Android vyuˇz´ıt ty nejz´akladnˇejˇs´ı, ze kter´ ych se d´a jak´akoli formul´aˇrov´a aplikace n´aslednˇe sloˇzit. K tˇemto objekt˚ um patˇr´ı textview“ (prvek pro popisek), edittext“ (prvek pro vkl´ad´an´ı textu), button“ ” ” ” (tlaˇc´ıtko) a prvek, do kter´eho je moˇzno vystupovat grafick´ y v´ ystup (tˇreba graf). K aktivn´ım“ objekt˚ um (napˇr´ıklad tlaˇc´ıtku) je moˇzno v jejich popisu tak´e pˇri” ˇradit jejich chov´an´ı pˇri jejich aktivaci (napˇr´ıklad stisknut´ı tlaˇc´ıtka). K tomu aby bylo moˇzno prov´est nˇejakou akci (respektive operaci), kter´a nen´ı souˇc´ast´ı p˚ uvodn´ıho k´odu polymorfn´ı aplikace, je nutno tento zdrojov´ y k´od operace nˇekde z´ıskat. K tomu lze pouˇz´ıt napˇr´ıklad spuˇstˇen´ı vzd´alen´eho k´odu ze serveru nebo st´ahnut´ı k´odu ze vzd´alen´eho u ´loˇziˇstˇe a jeho n´asledn´e spuˇstˇen´ı. Jsou moˇzn´e i dalˇs´ı varianty. Ty budou zm´ınˇeny v dalˇs´ıch kapitol´ach.
6
Pˇredpis chov´an´ı a podoby polymorfn´ı aplikace
Pˇred definov´an´ım objekt˚ u je nutno nejprve popsat, jak budou XML soubory zpracov´av´any. Zp˚ usob jejich zpracov´an´ı je pops´an v n´asleduj´ıc´ı kapitole.
7
4 Zpracov´av´an´ı XML Pro pˇreˇcten´ı souboru ve form´atu XML, kter´ y by mohl slouˇzit pro popis vzhledu grafick´eho uˇzivatelsk´eho rozhran´ı ˇci chov´an´ı generovan´e aplikace pro polymorfn´ı aplikaci, je potˇreba tzv. XML parser. Tedy prostˇredek pro rozpozn´an´ı dat uloˇzen´ ych v XML form´atu. Z obecn´eho hlediska existuj´ı dva z´akladn´ı druhy tˇechto XML parser˚ u. Kaˇzd´ y z nich m´a sv´e specifika a vyuˇz´ıv´a se k jin´emu u ´ˇcelu. Tyto dva druhy jsou tzv. SAX a DOM parsery.
4.1
DOM rozhran´ı
DOM rozhran´ı (z anglick´e zkratky pojmu Document Object Model“) je standardem ” W3C (neboli mezin´arodn´ıho konsorcia World Wide Web Consortium). Tzv. DOM parser pˇri zpracov´an´ı dat pˇristupuje k XML dokumentu jako k stromov´e datov´e struktuˇre (tato technologie se naz´ yv´a grove“ - neboli Graph Repre” ” sentation Of property ValuEs“). Jej´ı princip spoˇc´ıv´a v uloˇzen´ı cel´eho parsovan´eho XML dokumentu do vnitˇrn´ı pamˇeti, ve kter´e ho lze d´ale zpracov´avat, upravovat a napˇr´ıklad ukl´adat do nov´eho XML souboru. Hlavn´ı v´ yhodou, kromˇe toho, ˇze lze dokument upravovat, je i n´ahodn´ y a opakovan´ y pˇr´ıstup k dat˚ um naˇcten´ ym do stromov´e struktury bez nutnosti opakovan´eho ˇcten´ı p˚ uvodn´ıho XML souboru. Nev´ yhodou tohoto pˇr´ıstupu je vˇsak velk´a pamˇet’ov´a n´aroˇcnost (z d˚ uvodu uloˇzen´eho XML dokumentu ve vnitˇrn´ı pamˇeti po celou dobu zpracov´an´ı). Tuto nev´ yhodu ˇreˇs´ı tzv. sekvenˇcn´ı model SAX. V´ıce je tato problematika probr´ana ve ˇcl´anku viz [Kos01].
8
Zpracov´av´an´ı XML
4.2
SAX rozhran´ı
SAX rozhran´ı
SAX rozhran´ı neboli Simple API for XML“ bylo vytvoˇreno pro s´eriov´ y pˇr´ıstup ” k souboru ve form´atu XML. Principem zpracov´an´ı XML souboru pomoc´ı SAX je tzv. proudov´e zpracov´an´ı. Pˇri tomto zpracov´an´ı dojde k rozdˇelen´ı XML souboru na jednotliv´e ˇca´sti (napˇr. dle poˇca´teˇcn´ıch a koncov´ ych znaˇcek, XML element˚ u atd.). N´aslednˇe pak dojde k sekvenˇcn´ımu ˇcten´ı XML souboru po tˇechto ˇc´astech a program´ator m˚ uˇze zpracov´avat data dle poˇrad´ı, ve kter´em se v dan´em souboru nach´azela. Oproti DOM je SAX varianta ˇcasto rychlejˇs´ı na zpracov´an´ı a pamˇet’ovˇe m´enˇe n´aroˇcnˇejˇs´ı. Pamˇet’ov´a n´aroˇcnost je nejv´ıce znateln´a u zpracov´av´an´ı velk´ ych soubor˚ u, kde u DOM je ukl´ad´ano cel´e XML do vnitˇrn´ı pamˇeti. Avˇsak nev´ yhodou je to, ˇze cel´ y XML soubor je pˇreˇcten jednou a to dle poˇrad´ı, kter´e je d´ano obsahem zpracov´avan´eho souboru. Nelze tedy pˇristupovat k souboru v n´ahodn´em poˇrad´ı, jako je tomu u DOM. Z hlediska mobiln´ıch aplikac´ı je pro pouh´e z´ısk´an´ı dat z XML dokumentu lepˇs´ı pouˇz´ıt SAX parser, kter´ y tolik nezatˇeˇzuje zaˇr´ızen´ı, u kter´ ych se pˇredpokl´ad´a velmi omezen´a vnitˇrn´ı pamˇet’ a n´ızk´ y v´ ykon procesoru. V´ıce je tato problematika probr´ana ve ˇcl´anku viz [Kos01].
9
5 Vzd´alen´y k´od Jak bylo ˇreˇceno v pˇredchoz´ıch kapitol´ach, lze pro zpracov´an´ı u ´loh vyuˇz´ıt i k´odu, kter´ y nen´ı um´ıstˇen pˇr´ımo v dan´e aplikaci. Pro pouˇzit´ı vzd´alen´eho k´odu, je potˇreba vyˇreˇsit, jak d´at tento k´od aplikaci k dispozici. Vzd´alen´ y k´od lze napˇr´ıklad uchov´avat v podobˇe knihoven, kter´e se st´ahnou ze vzd´alen´eho u ´loˇziˇstˇe a za bˇehu aplikace provedou sv˚ uj k´od. Dalˇs´ı moˇznost´ı je k´od poskytovat na vzd´alen´ ych zaˇr´ızen´ıch, kter´a k´od provedou a vr´at´ı zpˇet v´ ysledek. Pro n´avrh popsan´eho principu pˇripadaj´ı v u ´vahu tˇri z´akladn´ı varianty ˇreˇsen´ı, kter´e budou pops´any v n´asleduj´ıc´ıch podkapitol´ach.
5.1
Varianta vol´ an´ı vzd´ alen´ ych procedur
RPC neboli Remote procedure call“ znamen´a v ˇceˇstinˇe Vzd´alen´e vol´an´ı procedur“. ” ” Pro mobiln´ı zaˇr´ızen´ı jsou nˇekter´e vykon´avan´e funkce velmi n´aroˇcn´e na v´ ypoˇcetn´ı sloˇzitost a to se m˚ uˇze projevit jak na poklesu v´ ykonu zaˇr´ızen´ı tak i napˇr´ıklad na spotˇrebˇe energie v pˇr´ıpadˇe pr´ace zaˇr´ızen´ı pˇres baterii. Proto m˚ uˇze b´ yt v´ yhodnˇejˇs´ı zpracovat poˇzadovan´ y k´od (respektive v´ ypoˇcet) na vzd´alen´em zaˇr´ızen´ı (napˇr. na specializovan´em v´ ypoˇcetn´ım serveru) a zpˇet poslat v´ ysledek operace. Jde o obdobu vol´an´ı lok´aln´ı funkce. Vol´an´ı tˇechto funkc´ı je zaloˇzeno na modelu klient-server, kde server m˚ uˇze b´ yt um´ıstˇen na vzd´alen´em zaˇr´ızen´ı v s´ıti. Klient-server model v tomto pˇr´ıpadˇe je zaloˇzen na tom, ˇze klient iniciuje komunikaci (respektive pos´ıl´a zpr´avu serveru) a po odesl´an´ı oˇcek´av´a od serveru zpr´avu s odpovˇed´ı. Pro vol´an´ı sluˇzeb je potˇreba zpr´avu s pˇred´avan´ ymi parametry pro pˇrij´ımaj´ıc´ı stranu zabalit. Princip RPC je tento: 1. Na stranˇe klienta nejprve dojde k zabalen´ı odes´ılan´ ych dat (parametr˚ u). Tento krok se naz´ yv´a jako tzv. marshalling“. ” 2. Klient provede odesl´an´ı zabalen´ ych dat serveru. 3. Na stranˇe zaˇr´ızen´ı zpracov´avaj´ıc´ıho data dojde k pˇr´ıjmu dat odeslan´ ych klientem. 4. Server provede rozbalen´ı pˇr´ıchoz´ıch dat. Tato operace se oznaˇcuje jako tzv. unmarshalling“. ” 10
Vzd´alen´y k´od
Varianta vol´an´ı vzd´alen´ych procedur
5. Server podle pˇrijat´e zpr´avy zajist´ı vol´an´ı spr´avn´e procedury (jej´ıˇz identifikace se pˇren´aˇs´ı v hlaviˇcce pˇren´aˇsen´e zpr´avy). 6. Server data zpracuje a pˇriprav´ı odpovˇed’ pro klienta. 7. Server data s v´ ysledkem operace zabal´ı a pˇriprav´ı k odesl´an´ı. 8. Server data s odpovˇed´ı/v´ ysledkem odeˇsle klientovi. 9. Klient, kter´ y operaci p˚ uvodnˇe poˇzadoval pˇrijme data od serveru. 10. Klient rozbal´ı data a zpracuje je. Cel´a komunikace prob´ıh´a pˇres spojky programu. Ty se oznaˇcuj´ı jako tzv. stub“. ” Stub“ je komunikaˇcn´ım rozhran´ım, kter´e RPC protokol implementuje. ” Kaˇzd´ y z prvk˚ u server-klient obsahuje jednu spojku. Na stranˇe serveru doch´az´ı k pˇriˇrazen´ı poˇzadovan´e procedury tak, ˇze z vnˇejˇs´ıho pohledu vypad´a toto chov´an´ı podobnˇe jako pˇri vol´an´ı lok´aln´ıch procedur. Nev´ yhoda RPC vˇsak spoˇc´ıv´a v tom, ˇze pro pˇrenos klient-server a server-klient je moˇzno pouˇz´ıt pouze z´akladn´ıch datov´ ych typ˚ u jazyka. Pˇrenos sloˇzitˇejˇs´ıch struktur prostˇrednictv´ım RPC lze realizovat vytvoˇren´ım vlastn´ıch struktur. Princip ˇcinnosti RPC je bl´ıˇze uk´az´an na obr´azku 5.1.
Obr´azek 5.1: Sch´ema ˇcinnosti RPC. Obr´azek vytvoˇren dle obr´azku z [Jav12]. Varianty RPC jsou pops´any v n´asleduj´ıc´ıch podkapitol´ach. 11
Vzd´alen´y k´od
5.1.1
Varianta vol´an´ı vzd´alen´ych procedur
XML-RPC
Protokol XML-RPC“ slouˇz´ı pˇredevˇs´ım pro vzd´alen´e komunikace s webov´ ymi sluˇz” bami. Je zaloˇzen na modelu klient-server, kde klient iniciuje komunikaci. Jak n´azev protokolu napov´ıd´a, jde o protokol, ve kter´em jsou data zapouzdˇrena do XML. Ta jsou pak pos´ıl´ana s´ıt’ov´ ym protokolem HTTP (resp. pomoc´ı tzv. HTTPPOST) na dan´ y server. Server na z´akladˇe vol´an´ı provede poˇzadovanou proceduru a zpˇet pomoc´ı stejn´eho mechanismu pos´ıl´a klientovi data s odpovˇed´ı (nebo informace o chybˇe). Uk´azka k´odu zpr´avy v XML-RPC (pˇrevzato z [Sci11]), kde se pˇren´aˇs´ı parametr typu integer (tedy cel´e ˇc´ıslo) pro zpracov´an´ı procedurou (v tomto pˇr´ıpadˇe jmenoMetody), kter´a se nach´az´ı ve tˇr´ıdˇe (v tomto pˇr´ıpadˇe trida) na stranˇe serveru:
HTTP/1.0 200 OK Connection: close Content-Length: 144 Content-Type: text/xml Date: Wed, 13 Apr 2013 12:00:00 GMT Server: ZCU client/1.0 <methodResponse> <params> <param> <string> Retezec s vysledkem operace
5.1.2
JSON-RPC
Protokol JSON-RPC“ (neboli JavaScript Object Notation - Remote procedure ” ” call“) je zaloˇzen na zak´odov´an´ı zpr´avy pomoc´ı JSON“. Jde o textov´ y form´at (nez´a” visl´ y na pouˇzit´em jazyce) urˇcen´ y pro v´ ymˇenu dat, kter´ y je zaloˇzen na podmnoˇzinˇe jazyka JavaScript dle standardu ECMA-262“ (v´ıce o tomto standardu v [Ecm11]). ” JSON vyuˇz´ıv´a dvou typ˚ u struktur. Prvn´ım typem je kolekce p´ar˚ u n´azev-hodnota. Ta b´ yv´a v jazyc´ıch ˇcasto realizov´ana objektem, z´aznamem (record ) nebo stukturou (struct). Druh´ ym typem struktur pro JSON jsou tˇr´ıdˇen´e seznamy hodnot. V jazyc´ıch je ˇcasto realizov´an jako pole (array), vektor (vector ), seznam (list) a nebo posloupnost (sequence). Citace viz [Jso13]. Komunikace v r´amci JSON-RPC prob´ıh´a obdobnˇe jako je tomu u XML-RPC. Tedy vol´an´ım procedury dojde k odesl´an´ı zpr´avy serveru (kter´ y implementuje JSONRPC protokol) pˇres TCP/IP socket. V pˇr´ıpadˇe nedostupnosti TCP/IP se m˚ uˇze 13
Vzd´alen´y k´od
Varianta vol´an´ı vzd´alen´ych procedur
pouˇz´ıt HTTP protokol. Klient sv´ ym vol´an´ım v jednu chv´ıli vol´a jednu zvolenou metodu. V pˇr´ıpadˇe, ˇze m´a dan´e vol´an´ı v´ıce vstupn´ıch parametr˚ u, dojde k jejich pˇred´an´ı dan´e metodˇe formou objektu nebo pole (viz v´ yˇse). Obdobn´ ym zp˚ usobem se pˇred´av´a zpˇet klientovi v´ ysledek operace proveden´ y metodou na stranˇe serveru (lze tedy navracet v´ıce v´ ystupn´ıch parametr˚ u v´ ysledku zpracovan´e metody). V pˇr´ıpadˇe pos´ıl´an´ı zpr´avy s poˇzadavkem na metodu (respektive odesl´an´ı poˇzadavku na metodu serveru) jde o zas´ıl´an´ı jednoho (serializovan´eho) JSON objektu. Objekt obsahuje n´asleduj´ıc´ı parametry: • methods - ˇretˇezec (string) jednoznaˇcnˇe identifikuj´ıc´ı metodu, kter´a je poˇzadov´ana pro proveden´e operace. • params - pole objekt˚ u, kter´e se maj´ı pouˇz´ıt pˇri zpracov´an´ı metody jako jej´ı vstupn´ı parametry. • id - hodnota jak´ehokoli typu, kter´a slouˇz´ı ke sp´arov´an´ı dotazu na server a odpovˇedi klientovi (respektive jde o to, aby klient spr´avnˇe rozpoznal odpovˇed’ na jeho vol´an´ı vzd´alen´e procedury). Odes´ılan´a zpr´ava by pak mohla pro pˇr´ıklad vypadat n´asledovnˇe: {"method": "echo", "params": ["Hello JSON-RPC"], "id": 1}
Po pˇr´ıjmu poˇzadavku a jeho zpracov´an´ı je zpˇet posl´ana odpovˇed’ s v´ ysledkem operace. Odpovˇed’ nese n´asleduj´ıc´ı parametry: • result - data s v´ ysledkem operace. V pˇr´ıpadˇe chyby zpracov´an´ı se v tomto parametru vrac´ı zpˇet hodnota null. • error - specifikace pomoc´ı chybov´eho k´odu o jakou ˇslo chybu. V pˇr´ıpadˇe, ˇze byla ˇcinnost vzd´alen´e procedury u ´spˇeˇsn´a, je v tomto parametru navr´acena hodnota null. • id - hodnota, kter´a pom´ah´a klientovi sp´arovat dotaz-odpovˇed’ ze serveru.
14
Vzd´alen´y k´od
Varianta vol´an´ı vzd´alen´ych procedur
Odpovˇed’ navazuj´ıc´ı na pˇredchoz´ı uk´azkov´ y pˇr´ıklad by pak tedy mohla vypadat n´asledovnˇe: {"result": "Hello JSON-RPC", "error": null, "id": 1}
V JSON-RPC existuje jeˇstˇe jeden speci´aln´ı druh odes´ılan´e zpr´avy pro pˇr´ıpad, ˇze se na server odes´ıl´a zpr´ava (ˇza´dost), k n´ıˇz se neoˇcek´av´a odpovˇed’ ze strany serveru. Tato zpr´ava je specifick´a t´ım, ˇze v parametru id obsahuje hodnotu null (jelikoˇz v tomto pˇr´ıpadˇe se neoˇcek´av´a odpovˇed’ a t´ım p´adem nen´ı s ˇc´ım zpr´avu sp´arovat). Uk´azkov´e pˇr´ıklady byly vytvoˇreny na z´akladˇe tutori´alu z [W3j99]. Pro mobiln´ı operaˇcn´ı syst´em Android existuje open-source knihovna android” json-rpc“. Tato knihovna je k dispozici pod MIT licenc´ı. Dalˇs´ı informace o t´eto knihovnˇe viz [Goo09].
5.1.3
SOAP
Protokol SOAP“ (z anglick´eho pojmu Simple Object Access Protocol“) vych´az´ı ” ” z principu v´ ymˇeny zpr´av pˇres s´ıt’. K tomu je ˇcasto vyuˇz´ıv´ano internetov´eho protokolu HTTP“ (neboli Hypertext Transfer Protocol“ - viz [Int99]). ” ” Data jsou u protokolu SOAP zapouzdˇrena v jazyce XML. Pro komunikaci se nejˇcastˇeji pouˇz´ıv´a RPC s modelem klient-server. Princip ˇcinnosti je n´asleduj´ıc´ı: 1. Klientsk´a aplikace odeˇsle zpr´avu s poˇzadavky na vykon´avanou proceduru ve form´atu XML na server. 2. Server zpr´avu pˇrijme. 3. Na serveru dojde k vykon´an´ı volan´e vzd´alen´e procedury. 4. Na stranˇe serveru je pˇripravena odpovˇed’ v XML form´atu. 5. Server poˇsle klientovi zpr´avu s odpovˇed´ı. 6. Klientsk´a aplikace zpr´avu od severu pˇrijme a zpracuje. 15
Vzd´alen´y k´od
Varianta vol´an´ı vzd´alen´ych procedur
SOAP zpr´avy maj´ı strukturu XML dokumentu. Koˇrenov´ ym elementem je element Envelope. V tomto koˇrenov´em elementu jsou dalˇs´ı dva elementy: • Header - tzv. hlaviˇcka je nepovinn´ ym elementem. Slouˇz´ı pouze jako doplˇ nkov´a informace, kter´a lze pouˇz´ıt pro zpracov´an´ı zpr´avy. M˚ uˇze b´ yt pouˇzita napˇr´ıklad pro identifikaci uˇzivatele apod. • Body - tzv. tˇelo je povinn´ ym parametrem, kter´ y identifikuje volan´e sluˇzby a parametry, kter´e maj´ı b´ yt volan´e proceduˇre pˇred´any. Uk´azka zpr´avy s poˇzadavky pos´ılan´ ych klientskou aplikac´ı na server:
Odpovˇed’ od serveru klientsk´e aplikaci by pak mohla m´ıt n´asleduj´ıc´ı podobu: HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <soap:Envelope xmlns:soap="http://www.w3.org/ 2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/ 2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPriceResponse> <m:Price>\textbf{34.5}
SOAP je pro Android dostupn´ y napˇr´ıklad v podobˇe knihovny ksoap2-android (viz [Goo10]). Ta je k dispozici pod MIT licenc´ı. Citace t´eto kapitoly a pˇr´ıklad˚ u viz [W3s99].
5.1.4
REST
REST“ (neboli z anglick´eho Representational State Transfer“) je architektura roz” ” hran´ı, navrˇzen´a pro distribuovan´e prostˇred´ı. Pojem REST byl poprv´e pˇredstaven v roce 2000 v disertaˇcn´ı pr´aci Roye Fieldinga, jednoho ze spoluautor˚ u protokolu HTTP ([Int99]). REST je oproti jiˇz zm´ınˇen´ ym XML-RPC (viz kapitola 5.1.1) ˇci SOAP (viz kapitola 5.1.3) orientov´an datovˇe nikoli procedur´alnˇe. Webov´e sluˇzby definuj´ı vzd´alen´e procedury a protokol pro jejich vol´an´ı, REST urˇcuje, jak se pˇristupuje k dat˚ um. Rozhran´ı REST je pouˇziteln´e pro jednotn´ y a snadn´ y pˇr´ıstup ke zdroj˚ um (tzv. resources“). Zdrojem mohou b´ yt data, stejnˇe jako stavy aplikace (pokud je lze ” 17
Vzd´alen´y k´od
Varianta distribuovan´ych objekt˚ u
popsat konkr´etn´ımi daty). Vˇsechny zdroje maj´ı vlastn´ı identifik´ator URI (Uniform Resource Identifier neboli jednotn´ y identifik´ator zdroje“) a REST definuje ˇctyˇri ” z´akladn´ı metody pro pˇr´ıstup k nim. Tyto metody se oznaˇcuj´ı jako CRUD“. Oznaˇcen´ı vzniklo spojen´ım prvn´ıch p´ı” smen n´azv˚ u jednotliv´ ych metod: • Create - metoda pro vytvoˇren´ı dat. Tato metoda je implementov´ana HTTP protokolem pomoc´ı metody POST. • Retrieve - metoda pro z´ısk´an´ı poˇzadovan´ ych dat. Tato metoda je implementov´ana HTTP protokolem pomoc´ı metody GET. • Update - metoda pro zmˇenu dat. Tato metoda je implementov´ana HTTP protokolem pomoc´ı metody PUT. • Delete - metoda pro maz´an´ı dat. Tato metoda je implementov´ana HTTP protokolem pomoc´ı metody DELETE. Zdroji mohou b´ yt napˇr´ıklad form´aty XML, JSON, RSS a ATOM. Citace viz [Mal09]. ˇ sen´ı REST je k dispozici i pro v´ Reˇ yvoj aplikac´ı v platformˇe Android, kter´e pˇristupuj´ı pomoc´ı rozhran´ı REST k dat˚ um webov´ ych sluˇzeb. V´ıce o tomto ˇreˇsen´ı v [Dob10].
5.2
Varianta distribuovan´ ych objekt˚ u
Tato varianta vyuˇz´ıv´a distribuovan´ ych objekt˚ u. Pomoc´ı mechanismu z´astupn´ ych objekt˚ u (tzv. proxy) lze pˇristupovat ke vzd´alen´ ym objekt˚ um stejn´ ym zp˚ usobem jako k lok´aln´ım. V´ıce o distribuovan´ ych objektech viz [Ocs10].
5.2.1
Java RMI
Java RMI (neboli Java Remote Method Invocation“) je prvn´ı technologi´ı progra” movac´ıho jazyka Java umoˇzn ˇuj´ıc´ı volat metody objekt˚ u nach´azej´ıc´ı se na jin´em JVM (neboli Java Virtual Machine“). ”
18
Vzd´alen´y k´od
Varianta distribuovan´ych objekt˚ u
Jde o architekturu klient-server, kde u ´kolem serveru je vytv´aˇret objekty a poskytovat reference na nˇe, tak aby byly vzd´alenˇe pˇr´ıstupn´e. Server po vytvoˇren´ı tˇechto objekt˚ u ˇcek´a, aˇz budou tyto objekty vol´any klientem (respektive klientskou aplikac´ı). Klient (respektive klientsk´a aplikace) vlastn´ı reference na objekty vytvoˇren´e serverem, aby mohl vzd´alenˇe volat jejich metody. Reference jsou v RMI um´ıstˇeny v registru, pˇriˇcemˇz server pomoc´ı tohoto registru zajiˇst’uje, aby byla asociov´ana jm´ena se vzd´alen´ ymi objekty. V pˇr´ıpadˇe, ˇze klient chce volat metodu vzd´alen´eho objektu, tak si ji vyhled´a dle jm´ena objektu v registru a vykon´a vol´an´ı t´eto metody. Vol´an´ı je zprostˇredkov´ano obdobnˇe jako tomu je u RPC pomoc´ı lok´aln´ıch z´astupn´ ych objekt˚ u, neboli spojek (stub). Princip Java RMI je uk´az´an na obr´azku 5.2, kde ˇc´ısla v obr´azku ud´avaj´ı poˇrad´ı prov´adˇen´ ych operac´ı. V´ıce o tomto t´ematu viz [Lyc11]. Java RMI je dostupn´e i pro mobiln´ı operaˇcn´ı syst´em Android. K tomu lze vyuˇz´ıt knihovnu android-xmlrpc. Ta je ˇs´ıˇrena v r´amci licence Apache License 2.0. Zdroj informac´ı pro tuto kapitolu byl vyuˇzit viz [Lyc11, Sch13].
Obr´azek 5.2: Uk´azka principu Java RMI. Obr´azek pˇrevzat z [Lyc11].
19
Vzd´alen´y k´od
5.2.2
Varianta distribuovan´ych objekt˚ u
CORBA
Standard CORBA“ (z anglick´eho Common Object Request Broker Architecture“) ” ” byla definov´ana skupinou OMG (neboli Object Management Group“) v ˇr´ıjnu roku ” 1991. Tento standard slouˇz´ı pro podporu tvorby distribuovan´ ych objektovˇe orientovan´ ych aplikac´ı. Je navrˇzen tak, aby komponenty napsan´e v r˚ uzn´ ych programovac´ıch jazyc´ıch a bˇeˇz´ıc´ıch na r˚ uzn´ ych poˇc´ıtaˇc´ıch mˇeli moˇznost spolu komunikovat. Komunikace v CORBA je navrˇzena na modelu klient-server. Klientsk´a aplikace pomoc´ı tzv. ORB (neboli Object Request Broker“) pˇristupuje k sluˇzb´am objekt˚ u ” zas´ıl´an´ım poˇzadavk˚ u. ORB obsahuje mechanismy pro vyhled´an´ı poˇzadovan´eho objektu (na stranˇe serveru), generov´an´ı poˇzadavk˚ u, jejich pˇrenos z klientsk´e aplikace na server a pˇrenos v´ ysledku zpˇet do klientsk´e aplikace (citace viz [Hul12]). Kaˇzd´ y objekt CORBA, kter´ y je poskytov´an serverem m´a definovan´e rozhran´ı v tzv. IDL (neboli Interface Definition Language“), kter´e specifikuje, jak´e objekty ” jsou na stranˇe serveru pˇr´ıstupn´e klientsk´ ym aplikac´ım. Pˇri v´ yvoji s CORBA je potˇreba nejprve nadefinovat pouˇz´ıvan´e rozhran´ı pomoc´ı IDL. Po kompilaci rozhran´ı pak dojde k vytvoˇren´ı Java tˇr´ıdy, klientsk´ ych spojek (tzv. stub“), kter´e slouˇz´ı k propojen´ı klientsk´eho k´odu s ORB agentem. D´ale je tak´e ” vytvoˇrena kostra objektu (tzv. skeleton“). Ta slouˇz´ı jako b´azov´a tˇr´ıda odpov´ıdaj´ıc´ı ” definici objektu v IDL. Pˇri vol´an´ı funkce objektu je vol´an´ı pˇresunuto pˇres klientskou spojku do ORB. Ten poˇsle poˇzadavek kostˇre volan´eho vzd´alen´eho objektu. Popsan´ y princip je vidˇet na obr´azku 5.3. Hlavn´ı nev´ yhodou tohoto ˇreˇsen´ı je to, ˇze CORBA vyuˇz´ıv´a komunikace na s´ıt’ov´em portu, kter´ y ˇcasto b´ yv´a na firewallech zak´az´an a je nutn´e ho manu´alnˇe na dan´em firewallu povolit. Pro platformu Android existuje ˇreˇsen´ı ve formˇe napˇr´ıklad knihovny TIDorb (viz [Gar11]) ˇs´ıˇren´ y pod GPL a Affero-GPL licencemi pro nekomerˇcn´ı pouˇzit´ı. Zdroje pouˇzit´e pro tvorbu t´eto kapitoly viz [Rho09, Cof13]. Specifikace a dalˇs´ı informace o aktu´aln´ı verzi CORBA 3.3 v [Cos13].
20
Vzd´alen´y k´od
Varianta k´odu z´ıskan´eho ze vzd´alen´eho u ´loˇziˇstˇe
Obr´azek 5.3: Uk´azka principu funkce CORBA. Obr´azek pˇrevzat z [Rho09].
5.2.3
DCOM
DCOM (z anglick´eho Distributed Component Object Model“) je propriet´arn´ı tech” nologie vyv´ıjen´a spoleˇcnost´ı Microsoft. Tato technologie umoˇzn ˇuje komunikovat r˚ uzn´ ym poˇc´ıtaˇc˚ um (prim´arnˇe s operaˇcn´ım syst´emem Microsoft Windows) spolu po s´ıti. Vyskytuje se i pro jin´e platformy v podobˇe implementace v komerˇcn´ıch produktech. Pro programovac´ı jazyk Java existuje napˇr´ıklad knihovna j-Interop implementuj´ıc´ı DCOM protokol pod LGPL licenc´ı. Nev´ yhodou je vˇsak, ˇze DCOM nekomunikuje prostˇrednictv´ım internetu. V´ıce o knihovnˇe j-Interop viz [Jin13]. Citace t´eto kapitoly pouˇzity z [Hul12]. Pro platformu Android bohuˇzel st´ale neexistuje DCOM podpora. V´ıce o t´eto technologii v [Msd07].
5.3
Varianta k´ odu z´ıskan´ eho ze vzd´ alen´ eho u ´ loˇ ziˇ stˇ e
Dalˇs´ı variantou je moˇznost staˇzen´ı funkˇcn´ıho k´odu ze vzd´alen´eho u ´loˇziˇstˇe. Vyuˇz´ıvat lze tak pouze k´od, kter´ y je zrovna potˇreba k vykon´av´an´ı dan´eho poˇzadavku. Toho 21
Vzd´alen´y k´od
Varianta k´odu z´ıskan´eho ze vzd´alen´eho u ´loˇziˇstˇe
je moˇzno dos´ahnout vytvoˇren´ım knihovny zabalen´e v jar souboru (v´ıce o form´atu jar v [Ibm13]). Program, kter´ y by mˇel m´ıt vˇseobecnou funkˇcnost (a tedy by jeho velikost byla teoreticky nekoneˇcn´a), je tak moˇzno rozdˇelit na velk´e mnoˇzstv´ı relativnˇe mal´ ych knihoven s poˇzadovan´ ymi funkcemi. Ve v´ yvojov´em prostˇred´ı Java pro Android lze vyuˇz´ıt tzv. DEX neboli Dalvik ” EXecutable“. Jde o platformu, kde java tˇr´ıdy .class lze zkompilovat do dex form´atu. Ten nen´ı tolik pamˇet’ovˇe n´aroˇcn´ y jako java k´od pro JVM (Java Virtual Machine). Rozd´ıl mezi klasick´ ym jar a dex ve f´azi pˇrekladu je vidˇet na obr´azku 5.4. Se standardn´ım jar m´a dex ve f´azi pˇrekladu soubor˚ u ve form´atu .java spoleˇcn´ y pˇreklad do bytecode (spustiteln´a mezik´od ve form´at .class). Pˇreklad zajiˇst’uje Java kompil´ator javac. Z´ıskan´ y soubor s bytecode je pak archivov´an pro norm´aln´ı Javu do form´atu .jar. Pro dex je vˇsak nutno z Java bytecode prov´est jeˇstˇe kompilaci na Dalvik bytecode. K proveden´ı kompilace na Dalvik bytecode existuje n´astroj nazvan´ y dx. Form´at dex vyuˇz´ıv´a operaˇcn´ı syst´em m´ısto pouˇzit´ı standardn´ıho javovsk´eho .class pro u ´sporu pamˇeti a optimalizaci na mobiln´ı zaˇr´ızen´ı. Obecnˇe uv´adˇen´a komprese k´odu je dex : jar pˇribliˇznˇe 0.44 : 1 (viz [Sra08]), coˇz je pomˇernˇe velk´a u ´spora uloˇzen´eho k´odu v pamˇeti.
Obr´azek 5.4: Sch´ema rozd´ılu mezi pˇrekladem jar a dex. Obr´azek vytvoˇren na z´akladˇe obr´azku z [Scr11]. Pro Android existuje moˇznost, jak naˇc´ıst Java tˇr´ıdy .class (uloˇzen´e v archivu .jar) za bˇehu aplikace. Realizace tohoto naˇc´ıt´an´ı je detailnˇe pops´ana v [Chu11]. 22
Vzd´alen´y k´od
Varianta k´odu z´ıskan´eho ze vzd´alen´eho u ´loˇziˇstˇe
Pˇri pouˇzit´ı je vˇsak nutno db´at na to, aby nebyly pouˇzity ˇz´adn´e knihovny, kter´e nejsou podporov´any syst´emem Android.
23
6 Android Mobiln´ı operaˇcn´ı syst´em Android je open source platforma zaloˇzen´a na j´adru Linuxu vyv´ıjena spoleˇcnost´ı Google. Prim´arn´ım u ´ˇcelem je nasazen´ı na chytr´e mobiln´ı telefony, tablety a obdobn´a zaˇr´ızen´ı.
6.1
Verze operaˇ cn´ıho syst´ emu Android
Mobiln´ı operaˇcn´ı syst´em Android byl od poˇc´atku sv´eho v´ yvoje rozliˇsov´an tˇremi druhy znaˇcen´ı. Prvn´ım je znaˇcen´ı tzv. API level (z anglick´eho Application Pro” gramming Interface“). Toto oznaˇcen´ı je d´ano ˇc´ıslem, kde vyˇsˇs´ı ˇc´ıslo ud´av´a novˇejˇs´ı verzi. Znaˇcen´ı je kl´ıˇcov´e pˇredevˇs´ım pro v´ yvoj´aˇre, kter´ ym ud´av´a, kter´e funkˇcnosti a prostˇredky mohou pro v´ yvoj v dan´e verzi pouˇz´ıt a kter´e jsou jiˇz nedoporuˇcen´e (tzv. deprecated“). ” Druh´ y typ oznaˇcen´ı ud´av´a verzi syst´emu. Znaˇcen´ı je zaloˇzeno na dvou a v´ıce ˇc´ıslech oddˇelen´ ych teˇckou. Prvn´ı ˇc´ıslo ud´av´a hlavn´ı verzi a dalˇs´ı dodatkov´a ˇc´ısla specifikuj´ı pˇresnˇe verzi dan´eho syst´emu. Posledn´ım typem znaˇcen´ı je k´odov´e znaˇcen´ı. Toto znaˇcen´ı je pojmenov´an´ım hlavn´ıch verz´ı syst´emu. Jm´ena se pˇriˇrazuj´ı dle anglick´ ych kulin´aˇrsk´ ych n´azv˚ u sladkost´ı a dezert˚ u. Pˇrehled verz´ı seˇrazen´ y od nejaktu´alnˇejˇs´ıch je vidˇet v tabulce 6.1. Verze operaˇcn´ıho syst´emu, kter´e maj´ı v aktivn´ıch zaˇr´ızen´ıch zastoupen´ı m´enˇe neˇz 0.1% v tabulce uvedeny nejsou. Aktivn´ıch zaˇr´ızen´ı s Android s API level rovn´emu 7 a m´enˇe je k datu 2. dubna 2013 dle zdroj˚ u Google v r´amci statistik obnovovan´ ych kaˇzd´ ych 14 dn´ı pomˇerovˇe k ostatn´ım verz´ım 1.8%. Z pr˚ ubˇeˇzn´ ych poznatk˚ u je moˇzno pozorovat rapidn´ı u ´bytek zaˇr´ızen´ı s niˇzˇs´ımi verzemi. Pro ty uˇz je tak´e podporov´ano ˇc´ım d´al m´enˇe novˇe vyv´ıjen´ ych aplikac´ı. Pro v´ yvoj polymorfn´ı aplikace byla zvolena minim´aln´ı verze 4.0 (odpov´ıdaj´ıc´ı API level 14). Tato verze je nasazov´ana na vˇetˇsinu nov´ ych mobiln´ıch zaˇr´ızen´ı. D´ıky rychl´emu v´ yvoji nov´ ych verz´ı syst´emu Android bude dostupn´ ych ˇc´ım d´al v´ıce zaˇr´ızen´ı s vyˇsˇs´ımi verzemi tohoto syst´emu.
Tabulka 6.1: Seznam vybran´ ych verz´ı operaˇcn´ıho syst´emu Android. V´ıce o aktu´aln´ıch statistik´ach aktivn´ıch zaˇr´ızen´ı, kter´e byly pouˇzity pro tento text, je moˇzno vidˇet v [Ded13].
6.2
V´ yvojov´ e prostˇ red´ı
Pro v´ yvoj pro mobiln´ı operaˇcn´ı syst´em lze vyuˇz´ıt celou ˇradu v´ yvojov´ ych prostˇredk˚ u, mezi kter´e patˇr´ı napˇr´ıklad Adobe AIR ˇci App Inventor. Velmi ˇcasto je tak´e vyuˇz´ıv´ano v´ yvojov´e prostˇred´ı Eclipse, kter´e je moˇzno st´ahnout vˇcetnˇe vˇsech potˇrebn´ ych knihoven a bal´ık˚ u (tedy vˇcetnˇe cel´eho SDK - Software development kit, respektive ADT Android Development Toolkit) pˇr´ımo z ofici´aln´ıch str´anek Android (viz [Sdk13]). Tento v´ yvojov´ y n´astroj poskytuje mnoho moˇznost´ı v´ yvoje, vˇcetnˇe pomˇernˇe dobˇre zpracovan´eho emul´atoru, dovoluj´ıc´ı v´ yvoj´aˇri testovat vytv´aˇren´e aplikace na emulovan´ ych zaˇr´ızen´ıch r˚ uzn´ ych druh˚ u s r˚ uzn´ ymi parametry. D´ıky t´eto vlastnosti se d´a odchytit vˇetˇsina nedostatk˚ u, kter´e by se mohly projevit na r˚ uzn´ ych konfigurac´ıch zaˇr´ızen´ıch se syst´emem Android vˇcetnˇe simulov´an´ı r˚ uzn´ ych nepˇredv´ıdateln´ ych situac´ı, kter´e mohou bˇeh aplikace naruˇsit. Jazyk, ve kter´em se pro operaˇcn´ı syst´em Android vyv´ıj´ı aplikace, je Java, pˇriˇcemˇz nˇekt´er´e knihovny (napˇr. pro Swing a ADT) nejsou k dispozici. Pro tvorbu uˇzivatelsk´eho rozhran´ı jsou vyuˇzity vlastn´ı knihovny (nedostupn´e v Java Standard Edition). D´ale jsou pro v´ yvoj aplikac´ı vyuˇz´ıvaj´ıc´ıch s´ıt’ov´ ych prostˇredk˚ u k dispozici knihovny Apache.
25
Android
Zajiˇstˇen´ı bezpeˇcnosti v syst´emu Android
Cel´a polymorfn´ı aplikace pro tuto pr´aci byla vyv´ıjena ve v´ yvojov´em prostˇred´ı Eclipse Juno 4.2.0 s ADT (verze 20.0.0.v201206242043-391819).
6.3
Zajiˇ stˇ en´ı bezpeˇ cnosti v syst´ emu Android
Bezpeˇcnost v mobiln´ıch aplikac´ıch je velmi d˚ uleˇzit´ ym t´ematem. Z hlediska dneˇsn´ı doby, kdy jsou ˇcast´e hrozby ze strany vnˇejˇs´ıch u ´tok˚ u na mobiln´ı zaˇr´ızen´ı, existuje i napˇr. moˇznost podvrhnut´ı aplikace (nebo jej´ı urˇcit´e ˇc´asti), kter´a se tv´aˇr´ı jako bezpeˇcn´a a uˇziteˇcn´a“ tzv. ˇskodliv´ ym k´odem“. ” ” Tento probl´em se m˚ uˇze pro pˇr´ıklad vyskytnou v aplikac´ıch zajiˇst’uj´ıc´ıch napˇr´ıklad internetov´e bankovnictv´ı, kde m˚ uˇze doj´ıt k v´aˇzn´e finanˇcn´ı ztr´atˇe uˇzivatele, zp˚ usoben´e zneuˇzit´ım osobn´ıch/pˇrihlaˇsovac´ıch u ´daj˚ u. Dalˇs´ı zp˚ usob zneuˇzit´ı se m˚ uˇze vyskytnout napˇr´ıklad u pos´ıl´an´ı pr´emiov´ ych SMS zpr´av bez vˇedom´ı uˇzivatele atd. Probl´emy s bezpeˇcnost´ı vˇsak mohou nastat i u aplikac´ı, jejichˇz ud´avan´a funkˇcnost nem´a na prvn´ı pohled nic spoleˇcn´eho s moˇzn´ ym nebezpeˇc´ım. V´ yvoj´aˇri syst´emu Android navrhli zp˚ usob zabr´anˇen´ı tˇemto u ´tok˚ um. Pro kaˇzdou aplikaci, jeˇz chce jej´ı v´ yvoj´aˇr pro syst´em Android napsat, mus´ı na zaˇca´tku definovat opr´avnˇen´ı, kter´e tato aplikace sm´ı vyuˇz´ıvat. Tato opr´avnˇen´ı jsou zaˇrazena do souboru (v XML form´atu), kter´ y se oznaˇcuje jako tzv. Android Manifest“. Opr´avnˇen´ı, kter´a ” je moˇzno pro aplikaci vyˇz´adat, je velk´a ˇrada. V pˇr´ıpadˇe, ˇze v´ yvoj´aˇr aplikace chce pouˇz´ıt nˇekterou z akc´ı ˇci pracovat s nˇejak´ ymi prostˇredky a nevyˇz´ad´a si pro nˇe dan´e opr´avnˇen´ı, reaguje Android na takov´ yto pokus znepˇr´ıstupnˇen´ım dan´ ych zdroj˚ u. Pro pˇr´ıklad, chce li v´ yvoj´aˇr, aby jeho aplikace mohla zapisovat do extern´ıho u ´loˇziˇstˇe (kter´ ym m˚ uˇze b´ yt napˇr´ıklad v zaˇr´ızen´ı vloˇzen´a SD karta) a nezad´a-li do manifestu poˇzadovan´e opr´avnˇen´ı, Android nedovol´ı t´eto aplikaci jak´ ykoli z´apis a vrac´ı zpˇet v´ yjimku (z anglick´eho Exception). Pro uk´azku moˇzn´ ych opr´avnˇen´ı, jsou zde uk´az´any ty nejˇcastˇeji pouˇz´ıvan´e: • android.permission.WRITE_EXTERNAL_STORAGE - pro povolen´ı z´apisu do extern´ı pamˇeti. • android.permission.READ_EXTERNAL_STORAGE - pro povolen´ı ˇcten´ı z extern´ı pamˇeti.
26
Android
Zajiˇstˇen´ı bezpeˇcnosti v syst´emu Android
• android.permission.WRITE_SMS - pro povolen´e naps´an´ı SMS zpr´avy. • android.permission.READ_SMS - pro povolen´ı ˇcten´ı SMS zpr´avy. • android.permission.ACCESS_NETWORK_STATE - pro zjiˇst’ov´an´ı stavu s´ıt’ov´eho pˇripojen´ı. • android.permission.INTERNET - pro povolen´ı pˇr´ıstupu aplikace k s´ıti. • android.permission.INSTALL_PACKAGES - pro povolen´ı instalov´an´ı nov´ ych bal´ıˇck˚ u (aplikac´ı). Dalˇs´ı moˇzn´a opr´avnˇen´ı je moˇzno vidˇet v [Dev13] a jejich pouˇzit´ı viz napˇr´ıklad [Mur11]. Princip ochrany uˇzivatele a mobiln´ıho zaˇr´ızen´ı, na kter´em m´a dan´a aplikace bˇeˇzet, je zaloˇzen na tom, ˇze pˇri instalaci dan´e aplikace mus´ı uˇzivatel potvrdit, ˇze s dan´ ymi opr´avnˇen´ımi souhlas´ı. D´ale pak uˇzivateli nezb´ yv´a, neˇz d˚ uvˇeˇrovat v´ yvoj´aˇri aplikace, ˇze vloˇzen´e d˚ uvˇery nezneuˇzije. Jednou z m´ala moˇznost´ı pasivn´ı ochrany proti zneuˇzit´ı je logick´a kontrola. Ta funguje tak, ˇze uˇzivatel, kter´ y instaluje aplikaci na zaˇr´ızen´ı, m´a moˇznost potvrdit souhlas pouˇzit´ı pr´av pro aplikaci. Uˇzivatel m´a moˇznost posoudit, zda je instalovan´a aplikace podezˇrel´a. Pro pˇr´ıklad aplikace, kter´a m´a funkci kalkulaˇcky je podezˇrel´a v pˇr´ıpadˇe, kdyˇz poˇzaduje opr´avnˇen´ı pro odes´ıl´an´ı SMS“ nebo pˇr´ıstup ke konta” kt˚ um uˇzivatele. V r´amci aktivn´ı ochrany dnes jiˇz existuj´ı antivirov´e programy, kter´e dok´aˇz´ı detekovat nebezpeˇcn´ y k´od (ˇci chov´an´ı) aplikace. Tyto aplikace funguj´ı tak, ˇze ˇcerpaj´ı znalosti z aplikac´ı, kter´e jiˇz na jin´ ych zaˇr´ızen´ı zp˚ usobily probl´emy a varuj´ı pˇred nimi uˇzivatele jiˇz ve f´azi pokusu o instalaci aplikace. V polymorfn´ı aplikaci tato problematika nab´ır´a velk´ ych rozmˇer˚ u. Probl´em je v tom, ˇze pokud je poˇzadavkem vytvoˇrit aplikaci, kter´a bude umˇet ˇsirokou ˇsk´alu operac´ı (funkˇcnost´ı), tak takov´ato aplikace bude tak´e potˇrebovat velk´ y rozsah dostupn´ ych opr´avnˇen´ı. Pro uˇzivatele tedy bude pˇri instalaci potvrzen´ı opr´avnˇen´ı pro vˇsechny aplikace matouc´ı a ke vˇsemu takto ztr´ac´ı veˇskerou kontrolu nad t´ım, co bude moci dan´a aplikace na jeho zaˇr´ızen´ı dˇelat.
27
Android
Zajiˇstˇen´ı bezpeˇcnosti v syst´emu Android
Jedn´ım z moˇzn´ ych ˇreˇsen´ı je vytvoˇren´ı r˚ uzn´ ych verz´ı polymorfn´ı aplikace. Napˇr´ıklad by mohly existovat dvˇe verze polymorfn´ı aplikace, kde jedna by mˇela napˇr´ıklad pouze z´akladn´ı pr´ava, kter´a by teoreticky nemohla nˇejak´ ym zp˚ usobem poˇskodit jak mobiln´ı zaˇr´ızen´ı tak i jeho uˇzivatele. Druh´a verze polymorfn´ı aplikace by pak mˇela vˇsechny moˇzn´a pr´ava, kter´a by se dala teoreticky pro aplikaci smysluplnˇe vyuˇz´ıt a uˇzivatel (a jeho mobiln´ı zaˇr´ızen´ı) by pak museli spol´ehat na d˚ uvˇeryhodnost poskytovatele ˇc´ast´ı aplikace (respektive na v´ yvoj´aˇre a poskytovatele podaplikac´ı“). ”
28
7 Realizace polymorfn´ı aplikace V r´amci t´eto diplomov´e pr´ace bylo navrˇzeno a realizov´ano ˇreˇsen´ı polymorfn´ı aplikace pro mobiln´ı operaˇcn´ı syst´em Android. V n´asleduj´ıc´ım textu je pops´an tento n´avrh a ˇreˇsen´ı.
7.1
Rozvrˇ zen´ı polymorfn´ı aplikace
Pro v´ yvoj aplikac´ı pro Android se vyuˇz´ıv´a tzv. aktivit“. Aktivita je programov´ y ” k´od, kter´ y definuje jednu zobrazovanou obrazovku“ vˇcetnˇe veˇsker´eho chov´an´ı v r´am” ci teto obrazovky. Aktivitu lze povaˇzovat za programovou entitu, kter´a slouˇz´ı k interakci s uˇzivatelem. Jedna aplikace se obecnˇe m˚ uˇze skl´adat z v´ıce jednotliv´ ych aktivit. Jedna z tˇechto aktivit je v manifestu“ aplikace pak oznaˇcena jako ta, kter´a se m´a spustit pˇri spuˇs” tˇen´ı aplikace. Z t´eto jsou pak ostatn´ı vyvol´av´any dle k´odu aktu´alnˇe spuˇstˇen´e aktivity. Pro polymorfn´ı aplikaci t´eto pr´ace bylo navrˇzeno prostˇred´ı skl´adaj´ıc´ı se ze dvou z´akladn´ıch aktivit. Prvn´ı aktivitou je tzv. hlavn´ı aktivita“, jej´ımˇz u ´kolem je d´at uˇzivateli moˇznost ” si zvolit poˇzadovanou generovanou aplikaci“ (respektive aktivitu, jej´ıˇz chov´an´ı a gra” fick´e uˇzivatelsk´e rozhran´ı bude ud´ano XML souborem s dan´ ym popisem), kter´a bude bˇeˇzet v r´amci druh´e pˇripraven´e aktivity. ´ Ukolem druh´eho typu aktivity je reprezentovat generovanou aplikaci“ dle zada” n´eho XML pˇredpisu poskytnut´eho prvn´ı ( hlavn´ı“) aktivitou. ” V r´amci dalˇs´ıho textu bude pro popis vytvoˇren´e polymorfn´ı aplikace vyuˇzit referenˇcn´ı obr´azek 7.1. Na zm´ınˇen´em obr´azku je vidˇet sch´ema popisuj´ıc´ı, jak polymorfn´ı ˇ aplikace funguje. Sipky v tomto obr´azku ud´avaj´ı komunikaci polymorfn´ı aplikace a budou d´ale v textu vysvˇetleny. V n´asleduj´ıc´ı ˇc´asti jsou pops´any jednotliv´e aktivity realizovan´e polymorfn´ı aplikace.
´ Ukolem hlavn´ı aktivity je d´at uˇzivateli moˇznost zvolit si poˇzadovan´e chov´an´ı a podobu grafick´eho uˇzivatelsk´eho rozhran´ı aplikace (v jin´em slova smyslu jde o v´ ybˇer generovan´e aplikace“). ” K tomu bylo v r´amci hlavn´ı aktivity navrˇzeno okno s jednou nab´ıdkou a dvˇemi tlaˇc´ıtky. Pro dodrˇzen´ı poˇzadavku co nejvˇetˇs´ı variability polymorfn´ı aplikace a moˇznost jej´ıho snadn´eho budouc´ıho rozˇs´ıˇren´ı, nebyla aplikace omezov´ana pouze na pˇrednastaven´e vzorov´e generovan´e aplikace“. Byla zvolena varianta, ve kter´e pomoc´ı uˇzi” vatelem zad´avan´e URL adresy se vzd´alen´ ym XML souborem popisuj´ıc´ım podobu a funkˇcnost aplikace, byla d´ana moˇznost uˇzivateli vybrat si, jakou aplikaci chce spustit (ze zadan´e URL adresy). Toto ˇreˇsen´ı bylo zvoleno, aby v´ yvoj´aˇri generovan´ ych aplikac´ı“ nebyly omezeni, ” jako by tomu bylo v pˇr´ıpadˇe, ˇze by veˇsker´a funkˇcnost byla pˇredem v aplikaci udan´a jej´ım p˚ uvodn´ım v´ yvoj´aˇrem. Uˇzivateli tedy staˇc´ı zadat spr´avnou adresu s XML souborem a m˚ uˇze aplikaci zaˇc´ıt pouˇz´ıvat. Hlavn´ı aktivita vych´az´ı z pr´ace [Hul12], kde se vˇsak jej´ı autor omezil pouze na dynamickou tvorbu rozhran´ı. Autor d´ale nepˇredpokl´adal vyuˇzit´ı vytvoˇren´e generovan´e aplikace bez nutnosti u ´prav k´odu samotn´e p˚ uvodn´ı aplikace. Ta byla vytvoˇrena a nastavena pouze na m´ıru dvˇema uk´azkov´ ym aplikac´ım ( kalkulaˇcka“ s jednoduch´ ymi ” funkcemi a pˇrevodn´ık teplot“). Pro dalˇs´ı moˇzn´e podoby“ aplikace by bylo nutn´e ” ” zmˇenit velkou ˇca´st zdrojov´eho k´odu samotn´e aplikace. Tato u ´prava by obn´aˇsela vloˇzen´ı veˇsker´e poˇzadovan´e funkˇcnosti pˇr´ımo do k´odu aplikace. Hlavn´ı aktivita vych´az´ı ze zm´ınˇen´e myˇslenky, avˇsak je dovedena k vˇetˇs´ı obecnosti s t´ım, ˇze nav´ıc podporuje myˇslenku zpracov´an´ı k´odu bez nutnosti jeho um´ıstˇen´ı v p˚ uvodn´ım zdrojov´em k´odu aplikace samotn´e. Funkce t´eto aktivity se skl´ad´a z nˇekolika f´az´ı. V prvn´ı f´azi je kontrolov´ano pˇripojen´ı k s´ıti. K tomu doch´az´ı, aby se zkontrolovala moˇznost st´ahnut´ı poˇzadovan´eho XML souboru s popisem generovan´e aplikace a pˇr´ıpadnˇe dalˇs´ıch potˇrebn´ ych soubor˚ u. Po tom, co uˇzivatel zad´a URL (z anglick´eho Uniform Resource Locator“) adresu s poˇzadovan´ ym XML souborem, se tato adresa ” uloˇz´ı do tzv. sd´ılen´ ych preferenc´ı“, odkud ji bude moˇzno dalˇs´ı aktivitou pˇreˇc´ıst. ” V dalˇs´ı f´azi se spust´ı nov´a aktivita (reprezentuj´ıc´ı generovanou aplikaci“). Spu” 31
Realizace polymorfn´ı aplikace
Aktivita pro generovan´e aplikace“ ”
ˇstˇen´ı t´eto aktivity je vidˇet v n´asleduj´ıc´ım uk´azkov´em zdrojov´em k´odu: Intent intent = new Intent(MainActivity.this, WorkClass.class); startActivity(intent);
Obr´azek 7.2: Uk´azka grafick´eho uˇzivatelsk´eho rozhran´ı hlavn´ı aktivity spuˇstˇen´e v emul´atoru. Hlavn´ı aktivita je z pohledu grafick´eho uˇzivatelsk´eho rozhran´ı sloˇzena z pole pro editovateln´ y text a dvou tlaˇc´ıtek. Do editovateln´eho pole se zad´av´a adresa poˇzadovan´eho XML souboru a tlaˇc´ıtkem Spustit se aktivita dan´a t´ımto XML spust´ı. Tlaˇc´ıtko Reset nastavuje pˇrednastaven´e XML do editovateln´eho pole. Dalˇs´ı prvky slouˇz´ı k zabezpeˇcen´ı a budou pops´any v kapitole 8. Jak tato aktivita vypad´a pˇri spuˇstˇen´ı v emul´atoru mobiln´ıch zaˇr´ızen´ı, je vidˇet na obr´azku 7.2.
7.3
Aktivita pro generovan´ e aplikace“ ”
Pˇri spuˇstˇen´ı t´eto aktivity dojde ke zjiˇstˇen´ı adresy XML souboru uloˇzen´e hlavn´ı aktivitou. N´aslednˇe je provedeno zkontrolov´an´ı dostupnosti XML souboru na adrese jeho pˇreˇcten´ım. 32
Realizace polymorfn´ı aplikace
Popis prostˇred´ı pomoc´ı XML
V obr´azku 7.1 je z´ısk´an´ı XML souboru zn´azornˇeno ˇsipkami oznaˇcen´ ymi A1 a A2. Dle popisu z´ıskan´eho z tohoto XML souboru dojde k vytvoˇren´ı uˇzivatelsk´eho prostˇred´ı v r´amci obrazovky dan´e aktivity (v obr´azku 7.1 zn´azornˇeno ˇsipkou oznaˇcenou jako D1. Aktivita dle z´ıskan´eho XML popisu tak´e zaˇrizuje, aby v pˇr´ıpadˇe, ˇze se nach´az´ı v popisu tlaˇc´ıtko (ˇci v´ıce tlaˇc´ıtek), byly k dispozici poˇzadovan´e zdroje. Zdroje jsou pro vytvoˇrenou polymorfn´ı aplikaci dvoj´ıho druhu. Prvn´ım jsou tlaˇc´ıtka vyuˇz´ıvaj´ıc´ı staˇzen´eho vzd´alen´eho k´odu. Tento druh tlaˇc´ıtka pro svou pr´aci pouˇz´ıv´a k´od staˇzen´ y ze vzd´alen´eho zdroje. Pro jeho spuˇstˇen´ı je nutno, aby tento k´od byl k dispozici na zaˇr´ızen´ı pˇred jeho pouˇzit´ım. Vzd´alen´ y k´od je tedy nutno otestovat na jeho dostupnost a v pˇr´ıpadˇe, ˇze je dostupn´ y, tak ho st´ahnout na lok´aln´ı zaˇr´ızen´ı. Tato varianta je oznaˇcovan´a jako DEX“. ” Obdobou, kter´a je v t´eto aktivitˇe tak´e dostupn´a, je spouˇstˇen´ı vzd´alen´eho k´odu (oznaˇcovan´eho jako RPC“), kde se kontroluje, zda je tento k´od dostupn´ y aˇz v mo” mentˇe jeho vyˇz´ad´an´ı. K tomu doch´az´ı, protoˇze existuje re´aln´a ˇsance, ˇze bˇehem doby, kdy je generovan´a aplikace“ spuˇstˇena, m˚ uˇze doj´ıt ke zmˇenˇe stavu serveru (napˇr´ıklad ” dojde k pˇreruˇsen´ı jeho ˇcinnosti) ˇci stavu pˇripojen´ı k s´ıti. Tedy v pˇr´ıpadˇe, ˇze napˇr´ıklad dojde k ztr´atˇe sign´alu potˇrebn´eho k pˇripojen´ı k s´ıti a s´ıt’ov´ ym sluˇzb´am. Popis, kter´ y byl vytvoˇren pro pops´an´ı vzhledu grafick´eho uˇzivatelsk´eho rozhran´ı generovan´ ych aplikac´ı“ a jejich chov´an´ı je vidˇet v n´asleduj´ıc´ı kapitole. ”
7.4
Popis prostˇ red´ı pomoc´ı XML
V kapitole 3 byly pops´any objekty potˇrebn´e pro tvorbu aplikac´ı s pˇrev´aˇznˇe formul´aˇrov´ ym zamˇeˇren´ım. Tyto objekty se popisuj´ı v XML souboru, kter´ y je jedn´ım z d˚ uleˇzit´ ych v´ ystup˚ u t´eto diplomov´e pr´ace. XML soubor pro popis generovan´e aplikace je reprezentac´ı jej´ıho grafick´eho uˇzivatelsk´eho rozhran´ı. Obsahuje jeden koˇrenov´ y element, kter´ y v sobˇe zapouzdˇruje vˇsechny objekty generovan´e aplikace. Tento element je oznaˇcen jako pro ud´an´ı zaˇca´tku popisu a pro konec popisu grafick´eho uˇzivatelsk´eho rozhran´ı generovan´e aplikace. V XML popisu tak lze popsat libovolnou formul´aˇrovou aplikaci s neomezen´ ym poˇctem objekt˚ u. Jednotliv´e objekty jsou ud´any elementem pro ukonˇcen´ı popisu objektu). 33
Realizace polymorfn´ı aplikace
Popis prostˇred´ı pomoc´ı XML
Popsan´e objekty jsou v polymorfn´ı aplikaci zobrazov´any aktivitou pro generovan´e aplikace. Aktivita pro generovan´e aplikace objekty shlukuje v poli, kde jednotliv´e ´ prvky jsou tzv. LinearLayout. Ukolem LinearLayout je v t´eto aktivitˇe zobrazovat jednotliv´e objekty vedle sebe. Kaˇzd´ y LinearLayout reprezentuje jednu ˇr´adku obˇ sen´ı jekt˚ u. Pole obsahuj´ıc´ı prvky LinearLayout je zapouzdˇreno do tzv. ScrollView. Reˇ vyuˇz´ıvaj´ıc´ı ScrollView ˇreˇs´ı probl´em, kter´ y vznikne pˇri zobrazov´an´ı v´ıce ˇr´adek, neˇz se vejde na obrazovku zaˇr´ızen´ı. Poskytuje totiˇz moˇznost rolov´an´ı obrazovky. Kaˇzd´ y z objekt˚ u m´a nˇejak´e vlastnosti. Tyto vlastnosti definuj´ı jak m´a objekt vypadat, tak i to, jak se m´a chovat. N´avrh popisu objekt˚ u vych´az´ı z myˇslenky pouˇzit´e v [Hul12]. Oproti nˇemu je vˇsak v ˇreˇsen´ı, pouˇzit´em v t´eto diplomov´e pr´aci, moˇzno pˇriˇrazovat jednotliv´ ym prvk˚ um jejich funkce nez´avisle na vytvoˇren´e polymorfn´ı aplikaci. Dalˇs´ım rozd´ılem je vˇetˇs´ı schopnost navrˇzen´ ym popisem ovlivˇ novat jak podobu, tak um´ıstˇen´ı jednotliv´ ych objekt˚ u. V n´asleduj´ıc´ım textu jsou popsan´e jednotliv´e objekty a jejich vlastnosti.
7.4.1
Objekt pro popisek
Objekt pro zobrazov´an´ı popisku m´a b´ yt prim´arnˇe informaˇcn´ım prvkem, kter´ y uˇzivatel nem˚ uˇze pˇrepisovat. Jde pouze o formu informaˇcn´ıho textu na obrazovce. Pro popis XML m´a tyto povinn´e elementy: • – Ud´av´a, ˇze jde o popisek (nastaven´ım na hodnotu textview“). ” • – Jednoznaˇcn´ y identifik´ator objektu v cel´em XML popisuj´ıc´ım uˇzivatelsk´e rozhran´ı. • – Jm´eno objektu v uˇzivatelsk´em rozhran´ı. • – Na jak´em ˇra´dku uˇzivatelsk´eho rozhran´ı se m´a tento objekt objevit (s ˇc´ıslov´an´ım od hodnoty 1). Mezi nepovinn´e elementy pak patˇr´ı: • – Jak´ y text se m´a v popisku objevit. V pˇr´ıpadˇe, ˇze je nevyplnˇen, nebo se v definiˇcn´ım XML souboru nevyskytuje, je povaˇzov´an za popisek s pr´azdn´ ym textem. 34
Realizace polymorfn´ı aplikace
Popis prostˇred´ı pomoc´ı XML
Objekt popisek m´a moˇznost pˇrepisovat sv˚ uj atribut text v pˇr´ıpadˇe, ˇze m´a zobrazovat nˇejakou uˇziteˇcnou dodateˇcnou informaci (napˇr´ıklad v´ ysledek operace). V n´asleduj´ıc´ı uk´azce je vidˇet, jak lze pomoc´ı XML popsat tento objekt:
7.4.2
Objekt pro zad´ avac´ı pole
´ Ukolem tohoto objektu je moˇznost zad´av´an´ı textu uˇzivatelem. Tento text m˚ uˇze b´ yt pˇredem omezen na napˇr´ıklad pouze ˇc´ıslice a podobnˇe. Pro popis XML m´a tyto povinn´e elementy: • – Ud´av´a, ˇze jde o zad´avac´ı pole (nastaven´ım na hodnotu edittext“). ” • – Jednoznaˇcn´ y identifik´ator objektu v cel´em XML popisuj´ıc´ım uˇzivatelsk´e rozhran´ı. • – Jm´eno objektu v uˇzivatelsk´em rozhran´ı • – Na jak´em ˇra´dku uˇzivatelsk´eho rozhran´ı se m´a tento objekt objevit (s ˇc´ıslov´an´ım od hodnoty 1). Mezi nepovinn´e elementy pak patˇr´ı: • – Jak´ y n´apovˇedn´ y text (tzv. hint“) se m´a v zad´avac´ım poli obje” vit. Pokud je nevyplnˇen, nebo se v definiˇcn´ım XML souboru nevyskytuje, je povaˇzov´an za zad´avac´ı pole bez n´apovˇedn´eho textu. • <subtype> – Ud´av´a, o jak´ y typ zad´avac´ıho pole se jedn´a. Tˇechto typ˚ u je nˇekolik: 35
Realizace polymorfn´ı aplikace
Popis prostˇred´ı pomoc´ı XML
– decimal – Form´at pro zad´av´an´ı pouze desetinn´ ych ˇc´ısel. – sigdecimal – Form´at pro zad´av´an´ı pouze desetinn´ ych ˇc´ısel se znam´enkem. – phone – Form´at pro zad´av´an´ı pouze telefonn´ıch ˇc´ısel. – date – Form´at pro zad´av´an´ı textu pouze v datumov´em form´atu. – text – Form´at pro zad´av´an´ı textu (pˇrednastaven´a hodnota pouˇzit´a v pˇr´ıpadˇe, ˇze nebyl nastaven ˇz´adn´ y jin´ y podtyp“). ” V n´asleduj´ıc´ı uk´azce je vidˇet, jak lze pomoc´ı XML popsat tento objekt:
7.4.3
Objekt reprezentuj´ıc´ı tlaˇ c´ıtko
Objekt, kter´ y je v XML pops´an s funkc´ı pro tlaˇc´ıtko, m´a za u ´kol sesb´ırat vˇsechny zadan´e hodnoty z pol´ı pro zad´av´an´ı (oznaˇcen´ ych jako edittext“) a ty poslat ke zpra” cov´an´ı. Tento objekt je hlavn´ım ovl´adac´ım prvkem generovan´e aplikace. Pro popis XML m´a tyto povinn´e elementy: • – Ud´av´a, ˇze jde o tlaˇc´ıtko (nastaven´ım na hodnotu button“). ” • – Jednoznaˇcn´ y identifik´ator objektu v cel´em XML popisuj´ıc´ım uˇzivatelsk´e rozhran´ı. • – Jm´eno objektu v uˇzivatelsk´em rozhran´ı • – Na jak´em ˇra´dku uˇzivatelsk´eho rozhran´ı se m´a tento objekt objevit (s ˇc´ıslov´an´ım od hodnoty 1).
36
Realizace polymorfn´ı aplikace
Popis prostˇred´ı pomoc´ı XML
• – Typ funkce, kter´a se m´a pouˇz´ıt. Jsou dva moˇzn´e typy: dex nebo rpc. • – Adresa, vzd´alen´eho k´odu. • – N´azev funkce, kter´a se m´a vykonat. Zad´an´ı je nutno prov´est ve form´at JmenoTridy.Funkce. • – Id objektu, kam se maj´ı uloˇzit v´ ysledky proveden´e akce. Pokud nem´a b´ yt v´ ysledek uloˇzen do ˇza´dn´eho objektu, obsahuje hodnotu -1. Mezi nepovinn´e elementy pak patˇr´ı: • – Text popisu tlaˇc´ıtka. Tento parametr je sice nepovinn´ y avˇsak z d˚ uvodu pˇrehlednosti programu vysoce doporuˇcen´ y. V n´asleduj´ıc´ı uk´azce je vidˇet, jak lze pomoc´ı XML popsat tento objekt:
7.4.4
Objekt reprezentuj´ıc´ı graf
Objekt, kter´ y je v XML pops´an pro graf (oznaˇcen´ y jako graph“) je oproti ostatn´ım ” objekt˚ um pomˇernˇe specifick´ y. Tento objekt se v norm´aln´ım v´ yvojov´em prostˇred´ı Androidu nevyskytuje. Jde o objekt speci´aln´ı knihovny Androidplot (viz [Apl12]). 37
Realizace polymorfn´ı aplikace
Popis prostˇred´ı pomoc´ı XML
´ Ukolem objektu je vykreslovat grafy dle z´ıskan´ ych dat. Pro popis XML m´a tyto povinn´e elementy: • – Ud´av´a, ˇze jde o tlaˇc´ıtko (nastaven´ım na hodnotu graph“). ” • – Jednoznaˇcn´ y identifik´ator objektu v cel´em XML popisuj´ıc´ım uˇzivatelsk´e rozhran´ı. • – Jm´eno objektu v uˇzivatelsk´em rozhran´ı • – Na jak´em ˇra´dku uˇzivatelsk´eho rozhran´ı se m´a tento objekt objevit (s ˇc´ıslov´an´ım od hodnoty 1). Mezi nepovinn´e elementy pak patˇr´ı: • – Hlavn´ı n´azev grafu (neboli text zobrazen´ y v hlaviˇcce grafu). • <axisX rel="nofollow"> – Popisek osy X v grafu. • <axisY rel="nofollow"> – Popisek osy Y v grafu. V n´asleduj´ıc´ı uk´azce je vidˇet, jak lze pomoc´ı XML popsat tento objekt:<br />
<br />
<object> <type>graph</type> <id>3</id> <nameOfObject>JmenoObjektu3</nameOfObject> <title>Popisek grafu4Osa XOsa Y
Tento objekt teoreticky pokr´ yv´a velkou mnoˇzinu pˇr´ıpad˚ u, kdy je potˇreba uˇzivateli d´at nˇejak´ y grafick´ y v´ ystup (napˇr´ıklad u grafick´e kalkulaˇcky to m˚ uˇze b´ yt pr˚ ubˇeh funkce atd.).
38
Realizace polymorfn´ı aplikace
7.5
Vzd´alen´y k´od
Vzd´ alen´ y k´ od
Jak jiˇz bylo ˇreˇceno v 5. kapitole, existuj´ı r˚ uzn´e moˇznosti, jak vyuˇz´ıt vzd´alen´ y k´od. Pro tuto pr´aci byly vybr´any nejvhodnˇejˇs´ı varianty tˇechto prostˇredk˚ u RPC a DEX. Obˇe tyto varianty byly pops´any v kapitole 5. Jejich pouˇzit´ı ve vytvoˇren´e polymorfn´ı aplikaci je uk´az´ano v n´asleduj´ıc´ıch podkapitol´ach.
7.5.1
RPC - vd´ alen´ e procedury
Prvn´ım typem je RPC, tedy prostˇredek pro vzd´alen´e vol´an´ı procedur. K tomuto prostˇredku existuj´ı dvˇe z´akladn´ı varianty popsan´e v kapitole 5. Pro vytvoˇrenou polymorfn´ı aplikaci byla pouˇzita varianta XML-RPC s vyuˇzit´ım knihovny Apache XML-RPC (viz [Apa10]). Ta byla pouˇzita z d˚ uvodu jej´ı jednoduch´e pouˇzitelnosti pˇri dalˇs´ı tvorbˇe generovan´ ych aplikac´ı pro vytvoˇrenou polymorfn´ı aplikaci. Princip t´eto varianty je takov´ y, ˇze nˇekter´ y z ovl´adac´ıch prvk˚ u (tlaˇc´ıtko) m´a pˇriˇrazen´e vol´an´ı vzd´alen´e procedury RPC“ jako zp˚ usob reakce na ud´alost. Tou je ” stisknut´ı tlaˇc´ıtka, kter´e m´a nastaveno ve sv´em XML popisu element n´asleduj´ıc´ım zp˚ usobem: rpc. Pokud nastane tento pˇr´ıpad, tak se vezme adresa serveru, kter´a je pˇridruˇzena tomuto ovl´adac´ımu prvku (tlaˇc´ıtku) a n´azev vzd´alen´e procedury, kter´a m´a b´ yt na serveru vykon´ana ke zpracov´an´ı dat. Uk´azka parametr˚ u specifikovan´ ych v XML pro dan´ y ovl´adac´ı prvek je vidˇet d´ale:
Vol´an´ı procedury na serveru pak prob´ıh´a dle zdrojov´eho k´odu, kter´ y odpov´ıd´a n´asleduj´ıc´ı uk´azce:
XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl(); config.setServerURL(new URL("http://192.168.10.103:8080/ xml-rpc-server/xmlrpc")); XmlRpcClient client = new XmlRpcClient(); client.setConfig(config); Object[] params = new Object[]{new Integer(33), new Integer(9)}; Integer result = (Integer)client.execute("Calculator.add",params);
V t´eto uk´azce je vidˇet vol´an´ı serveru (respektive XML-RPC serveru) provozovan´eho na s´ıt’ov´e adrese udan´e elementy v XML popisu (viz pˇr´ıklad v´ yˇse). Na serveru je poˇzadov´ano vol´an´ı procedury add um´ıstˇen´e ve tˇr´ıdˇe Calculator. Pro pˇred´an´ı parametr˚ u, potˇrebn´ ych pro spr´avn´ y bˇeh vzd´alen´e procedury, je pouˇzito pole objekt˚ u (Object[]) nazvan´e params. V uk´azce jsou pˇren´aˇseny dvˇe hodnoty ˇc´ısla typu cel´e ˇc´ıslo (neboli integer hodnot 33 a 9). Pro spr´avnou funkci vˇsak mus´ı strana serveru pˇrij´ımat stejn´ y poˇcet a typy promˇenn´ ych, jinak doch´az´ı k chybˇe a t´ım p´adem neproveden´ı poˇzadovan´e procedury serveru. To plat´ı i opaˇcnˇe, tedy pˇri pˇred´av´an´ı v´ ysledk˚ u ze serveru ke klientovi, kdy je nutn´e pˇrij´ımat stejn´ y typ a poˇcet dat poslan´ ych od serveru klientsk´e aplikaci. V´ ysledek operace proveden´e na vzd´alen´e proceduˇre serveru je po jej´ım proveden´ı uloˇzen do hodnoty result typu integer. Obecnˇe vˇsak lze pouˇz´ıt jak´ ykoli typ objektu ˇci struktury sloˇzen´e ze z´akladn´ıch datov´ ych typ˚ u programovac´ıho jazyka. K tomu, aby server mohl poskytnout odpovˇed’, je potˇreba na serveru m´ıt v danou chv´ıli spuˇstˇenou odpov´ıdaj´ıc´ı sluˇzbu. Tato sluˇzba bude pomoc´ı XML-RPC knihovny z´ısk´avat dotazy od klient˚ u, zpracov´avat je a pos´ılat zpˇet poˇzadovan´e v´ ysledky proveden´e operace. Server volanou proceduru zapouzdˇruje v tˇr´ıdˇe (viz pˇr´ıklad v´ yˇse Calculator).
40
Realizace polymorfn´ı aplikace
Vzd´alen´y k´od
Uk´azka funkce volan´e na stranˇe serveru vypad´a n´asledovnˇe:
package org.apache.xmlrpc.demo; public class Calculator { public int add(int i1, int i2) { return i1 + i2; } public int subtract(int i1, int i2) { return i1 - i2; } }
V uk´azce jsou vidˇet dvˇe metody, kter´e je moˇzn´e na serveru ze tˇr´ıdy Calculator volat. Prvn´ı sˇc´ıt´a dva vstupn´ı parametry a druh´a prov´ad´ı odeˇc´ıt´an´ı druh´eho parametru od prvn´ıho. K tomu aby takov´eto vol´an´ı mohlo fungovat, je potˇreba na serveru vytvoˇrit jeˇstˇe soubor XmlRpcServlet.properties, kter´ y specifikuje tˇr´ıdy dostupn´e na serveru. Tento soubor je tˇreba vytvoˇrit ve specifick´e sloˇzce serveru (pro uk´azkov´ y pˇr´ıklad by ˇslo o org/apache/xmlrpc/webserver) a do nˇej uloˇzit n´asleduj´ıc´ı pˇr´ıkaz:
Calculator=org.apache.xmlrpc.demo.Calculator
V pˇr´ıpadˇe, ˇze je potˇreba pˇridat v´ıce tˇr´ıd na dan´ y server, tak se do tohoto souboru pˇridaj´ı pouze dalˇs´ı ˇra´dky dle uveden´eho vzoru. N´aslednˇe je pak potˇreba upravit soubor web.xml napˇr´ıklad dle n´asleduj´ıc´ı uk´azky:
Sets, whether the servlet supports vendor extensions for XML-RPC. <servlet-mapping> <servlet-name>XmlRpcServlet /xmlrpc
Uk´azky klientsk´e i serverov´e ˇc´asti jsou pˇrevzaty z [Apc10, Aps10] a v modifikovan´e podobˇe pouˇzity ve vytvoˇren´e polymorfn´ı aplikaci. Pro vytvoˇrenou polymorfn´ı aplikaci bylo v z´akladn´ı podobˇe pouˇzito postupu, ˇze pˇred odesl´an´ım parametr˚ u na server jsou sesb´ır´ana vˇsechna data urˇcen´a pro odesl´an´ı. Jde o proch´azen´ı vˇsemi editovateln´ ymi textov´ ymi poli (objekty typu edittext a jejich obdob) a uloˇzen´ı jejich obsahu do dynamick´eho pole - kolekce ArrayList<String>. N´aslednˇe je ovˇeˇrena dostupnost serveru (pomoc´ı chybov´e odpovˇedi s ˇc´ıslem 405, kterou v pˇr´ıpadˇe vol´an´ı HTTP poˇzadavku vrac´ı server pokud na nˇem bˇeˇz´ı XMLRPC server ). Pokud server odpov´ı na tento poˇzadavek spr´avnˇe, jsou mu pomoc´ı pole objekt˚ u (Object[] params) pˇred´any vstupn´ı parametry. Vstupn´ı parametry jsou z´ısk´any z kolekce obsah˚ u editovateln´ ych pol´ı. Pole objekt˚ u s parametry je pak odesl´ano serveru zavol´an´ım funkce execute() nad objektem typu XmlRpcClient (v obr´azku 7.1 je odesl´an´ı poˇzadavku na server oznaˇceno jako B1).
V´ ysledek operace je pak navr´acen do pole objekt˚ u outObjectArray (na obr´azku 7.1 je z´ısk´an´ı v´ ysledku operace oznaˇceno jako B2). V tomto poli se na prvn´ı pozici nach´az´ı k´odov´e ˇc´ıslo stavu operace. V pˇr´ıpadˇe, ˇze bˇehem operace na stranˇe serveru nemohla b´ yt data zpracov´ana (a to bud’ ˇspatn´ ym form´atem, poˇrad´ım nebo obsahem vstupn´ıch dat), je navr´acena z´aporn´a hodnota na pozici prvn´ıho parametru. Pokud k tomu dojde, je druh´ ym parametrem text chybov´eho hl´aˇsen´ı, kter´e se m´a uˇzivateli zobrazit na obrazovce.
42
Realizace polymorfn´ı aplikace
Vzd´alen´y k´od
Jak jiˇz bylo zm´ınˇeno, pokud je operace na serveru u ´spˇeˇsnˇe provedena, tak je vr´aceno kladn´e ˇc´ıslo v prvn´ım parametru. Druh´ ym parametrem je hl´aˇsen´ı, kter´e se m´a uˇzivateli zobrazit na obrazovce zaˇr´ızen´ı. Dalˇs´ı parametry jsou pak rozliˇseny k´odov´ ym ˇc´ıslem stavu operace. V pˇr´ıpadˇe, ˇze hodnota byla r˚ uzn´a od hodnoty ˇc´ısla 2, tak je podle tlaˇc´ıtka, kter´e operaci volalo, nalezen objekt, kter´emu se m´a jako popisek“ nastavit posledn´ı (tˇret´ı) parametr. Tento objekt je urˇcen hodnotou udanou ” u objektu (respektive tlaˇc´ıtka), kter´e danou operaci volalo elementem udan´ ym v XML souboru popisuj´ıc´ım podobu prostˇred´ı polymorfn´ı aplikace. Pokud vˇsak je hodnota k´odov´eho stavu operace nastavena na hodnotu ˇc´ısla 2, jde o objekt vykreslen´ı do objektu typu graph (neboli grafu). Pro graf je moˇzno, aby za prvn´ımi dvˇema parametry (popsan´ ymi v´ yˇse) bylo vˇetˇs´ı mnoˇzstv´ı parametr˚ u typu String (neboli textov´ y ˇretˇezec). Kaˇzd´ y z tˇechto ˇretˇezc˚ u m´a pak tvar:
N´ azevGrafu@x1;y1;x2;y2;x3;y3; ...
Symbolick´e promˇenn´e (x1,y1 atd.) jsou ve skuteˇcn´em ˇretˇezci oproti t´eto uk´azce nahrazeny hodnotami ud´avaj´ıc´ımi souˇradnice bod˚ u v os´ach x a y kˇrivky, kter´a se m´a v grafu vykreslit. Znakov´ y symbol @“ slouˇz´ı v ˇretˇezci k oddˇelen´ı n´azvu grafu a sou” ˇradnic kˇrivky grafu. Pokud se oddˇeluj´ıc´ı symbol v ˇretˇezci nenach´az´ı, je pro textov´ y popisek grafu pouˇzito pˇrednastaven´e pojmenov´an´ı Graph“. ” Poˇzadovan´ y graf se urˇcuje stejn´ ym zp˚ usobem jako se v pˇredchoz´ım popisu ud´aval objekt, do kter´eho se mˇel vypsat popisek z n´avratov´eho ˇretˇezce (tedy pˇres element idOfResult, kter´ y je zadan´ y u objektu typu tlaˇc´ıtko v XML popisuj´ıc´ım podobu polymorfn´ı aplikace).
7.5.2
DEX - k´ od ze vzd´ alen´ eho u ´ loˇ ziˇ stˇ e
Druh´ ym typem prostˇredku pro zpracov´an´ı operac´ı je tzv. DEX“. Obecn´ y princip ” ˇcinnosti t´eto varianty byl pops´an v kapitole 5.3. Varianta je zaloˇzena na staˇzen´ı vzd´alen´eho k´odu ve form´atu dex na lok´aln´ı zaˇr´ızen´ı (na obr´azku 7.1 je kontrola existence DEX souboru na u ´loˇziˇsti oznaˇcena jako C1 a jeho staˇzen´ı samotn´e do zaˇr´ızen´ı jako C2). Tato varianta pouˇz´ıv´a pro XML popis dan´eho ovl´adac´ıho prvku slouˇz´ıc´ıho k operac´ım s DEX podobn´ y syntaktick´ y z´apis, jako tomu bylo ve variantˇe RPC popsan´e v pˇredchoz´ı kapitole 7.5.1.
43
Realizace polymorfn´ı aplikace
Vzd´alen´y k´od
Pro uk´azku lze uv´est n´asleduj´ıc´ı pˇr´ıklad: http://home.zcu.cz/~staffa/DexLibrary.jar dex Calculator.add V r´amci tˇechto element˚ u uveden´ ych u ovl´adac´ıho prvku (respektive tlaˇc´ıtka) je moˇzno vidˇet, jak´e DEX se m´a pouˇz´ıt pro vykon´an´ı poˇzadovan´e operace. Element ud´av´a adresu, kde se nach´az´ı dan´ y DEX v URL form´atu. Ten, jak je vidˇet z t´eto uk´azky, vˇsak nen´ı v oˇcek´avan´em form´atu .dex, ale je zapouzdˇren ve form´atu souboru .jar, zde bude vˇsak oznaˇcov´an jako DEX. V programovac´ım jazyku Java existuje komponenta (tzv. ClassLoader), kter´a se star´a o nahr´av´an´ı tˇr´ıd do aplikace. V Javˇe i Androidu vˇsak existuje moˇznost, jak za bˇehu nahr´at do aplikace extern´ı“ tˇr´ıdu. Tyto tˇr´ıdy pak mohou b´ yt um´ıstˇeny ” na vzd´alen´em u ´loˇziˇsti ˇci na lok´aln´ım souborov´em syst´emu. Pro samotn´e naˇc´ıt´an´ı tˇr´ıd se vyuˇz´ıv´a tzv. DexClassLoader, kter´ y umoˇzn ˇuje naˇc´ıtat DEX soubory za bˇehu aplikace. Polymorfn´ı aplikace je vytvoˇrena tak, ˇze v pˇr´ıpadˇe nedostupnosti s´ıt’ov´eho pˇripojen´ı lze vyuˇz´ıvat i DEX soubory, kter´e byly pouˇzity jako posledn´ı. K tomu je vˇsak nutn´e, aby pˇri u ´plnˇe prvn´ım spuˇstˇen´ı generovan´e aplikace, kter´a bude vyuˇz´ıvat dan´ y DEX, byl tento DEX staˇzen. V pˇr´ıpadˇe dostupnosti pˇripojen´ı je pˇri spuˇstˇen´ı generovan´e aplikace poˇzadovan´ y DEX vˇzdy staˇzen. D˚ uvodem tohoto ˇreˇsen´ı je, aby v pˇr´ıpadˇe aktualizace DEX soubor˚ u poskytnut´ ych v´ yvoj´aˇrem/distributorem na u ´loˇziˇsti byly vˇzdy pouˇzity aktu´aln´ı verze (respektive byly vˇzdy znovu st´ahnuty za pˇredpokladu s´ıt’ov´eho pˇripojen´ı). V polymorfn´ı aplikaci byl pro staˇzen´ı DEX knihoven zvolen n´asleduj´ıc´ı zp˚ usob. Po pˇreˇcten´ı a parsov´an´ı XML souboru, kter´ y popisuje danou generovanou aplikaci, dojde k proch´azen´ı vˇsech ovl´adac´ıch prvk˚ u (tlaˇc´ıtek) a zjiˇstˇen´ı adresy DEX v XML souboru, pokud maj´ı nastaven DEX jako obsluˇzn´ y typ operace. Adresy se uloˇz´ı do ArrayList<String> arrayOfAddresses. Potom je ArrayList proch´azen po jednotliv´ ych uloˇzen´ ych z´aznamech a jsou stahov´any potˇrebn´e DEX soubory. 44
Realizace polymorfn´ı aplikace
Vzd´alen´y k´od
V tomto kroku existuj´ı dvˇe varianty. Prvn´ı je ta, ˇze pokud je k dispozici pˇripojen´a a pro ˇcten´ı/z´apis dostupn´a extern´ı pamˇet’ (napˇr´ıklad tzv. SD karta), tak je DEX uloˇzen na ni. To je z d˚ uvodu u ´spory intern´ı pamˇeti na mobiln´ıch zaˇr´ızen´ıch. V pˇr´ıpadˇe, ˇze extern´ı u ´loˇziˇstˇe k dispozici nen´ı, je pouˇzita intern´ı pamˇet’ov´a oblast urˇcen´a pro data aplikac´ı. Ta je pro vytvoˇrenou polymorfn´ı aplikaci ud´ana cestou data/data/dpapp1. Samotn´e stahov´an´ı soubor˚ u DEX pak vypad´a pˇribliˇznˇe dle n´asleduj´ıc´ı uk´azky:
InputStream input = new BufferedInputStream(url.openStream()); File myDir; if (isSDCardPresent) { String root = Environment.getExternalStorageDirectory().toString(); myDir = new File(root + "/Android/data/" + PACKAGE_NAME + "/"); } else { myDir = new File("/data/data/" + PACKAGE_NAME + "/dex/"); } OutputStream output = new FileOutputStream(myDir + "/" + nameOfFile); byte data[] = new byte[1024]; long total = 0; int count; //read data while ((count = input.read(data)) != -1) { total += count; // publishing the progress.... publishProgress((int) (total * 100 / fileLength)); output.write(data, 0, count); } output.flush(); output.close(); input.close();
45
Realizace polymorfn´ı aplikace
Vzd´alen´y k´od
N´aslednˇe je pak nutn´e pˇri vol´an´ı akc´ı nad tˇemito DEX soubory dan´e soubory zpracovat. K tomu je potˇreba zn´at rozhran´ı (respektive interface) pro pˇr´ıstup k procedur´am, kter´e jsou poskytov´any t´ımto DEX. Aby bylo vytv´aˇren´ı a pouˇz´ıv´an´ı DEX soubor˚ u co nejpˇrehlednˇejˇs´ı, byla zvoleno n´asleduj´ıc´ı rozhran´ı:
public interface LibraryInterface { public ArrayList<String> doLibraryFunction(String nameOfFunction, ArrayList<String> params); }
Z uk´azkov´eho pˇr´ıkladu je vidˇet, ˇze zp˚ usob vol´an´ı procedury je hodnˇe podobn´ y vol´an´ı procedury u RPC uveden´eho v pˇr´ıkladu v pˇredchoz´ı kapitole 7.5.1. K samotn´emu naˇcten´ı tˇr´ıdy s poˇzadovanou procedurou potˇrebujeme jiˇz zm´ınˇen´ y DexClassLoader. V pˇr´ıloze B je vidˇet jeho pouˇzit´ı. Jak je z tohoto uk´azkov´eho zdrojov´eho k´odu vidˇet, podobnˇe jako v kapitole 7.5.1 o RPC je navr´acen k´od stavu operace. Dalˇs´ımi parametrem je stejnˇe jako u zm´ınˇen´eho RPC text, kter´ y m´a b´ yt vyps´an ve formˇe informaˇcn´ıho textov´eho pole na obrazovku. Posledn´ımi parametry jsou zpˇetn´a data pro vykreslen´ı grafu ˇci vyps´an´ı textu do jednoho z textov´ ych pol´ı/objekt˚ u generovan´e aplikace. Vytvoˇren´ y DEX soubor je pak zaloˇzen napˇr´ıklad na n´asleduj´ıc´ı uk´azce k´odu:
public class DexLibrary implements LibraryInterface{ public ArrayList<String> doLibraryFunction (String nameOfFunction, ArrayList<String> params) { int first = 0; int second = 0; int result = 0; ArrayList<String> outputArray = new ArrayList<String>(); if (nameOfFunction.equals("add")) { try 46
Podm´ınka t´eto varianty spoˇc´ıv´a v dodrˇzen´ı vstupn´ıho a v´ ystupn´ıho form´atu dat. Dalˇs´ı d˚ uleˇzitou podm´ınkou je to, ˇze dan´a DEX knihovna (v tomto pˇr´ıpadˇe s n´azvem DexLibary) mus´ı m´ıt stejn´e jm´eno jako .jar soubor, ve kter´em je distribuov´ana. V opaˇcn´em pˇr´ıpadˇe operace proveden´a nad touto knihovnou konˇc´ı chybou. V´ yvoj´aˇri pro navrhov´an´ı vlastn´ıch aplikac´ı n´aslednˇe staˇc´ı pouze vytvoˇrit popisov´e XML (pro popis chov´an´ı a uˇzivatelsk´eho rozhran´ı generovan´e aplikace) a dle toho, zda chce vyuˇz´ıvat RPC ˇci DEX, vytvoˇrit danou knihovnu ˇci server poskytuj´ıc´ı poˇzadovan´e procedury. Navrˇzen´e ˇreˇsen´ı bylo realizov´ano na z´akladˇe v´ yzkumu z [Chu11, Hul12].
47
8 Bezpeˇcnost polymorfn´ı aplikace V kapitole 6.3 byla z obecn´eho hlediska pops´ana bezpeˇcnost aplikac´ı v mobiln´ıch zaˇr´ızen´ıch se syst´emem Android. N´asleduj´ıc´ı kapitola se zab´ yv´a popisem probl´em˚ u s bezpeˇcnost´ı vzhledem k vytvoˇren´e polymorfn´ı aplikaci a jejich ˇreˇsen´ım.
8.1
Novˇ e vznikl´ e probl´ emy bezpeˇ cnosti
N´avrhem polymorfn´ı aplikace pro tuto pr´aci vyvstaly nov´e probl´emy s bezpeˇcnost´ı. Za prv´e jde o jiˇz zm´ınˇen´e velk´e mnoˇzstv´ı potˇrebn´ ych pr´av nutn´ ych pˇri pouˇzit´ı DEX varianty. D˚ uvodem tohoto poˇzadavku je, aby polymorfn´ı aplikace mohla b´ yt co nejˇ v´ıce vˇsestrann´a, k ˇcemuˇz potˇrebuje velk´ y rozsah pr´av. Reˇsen´ım je, ˇze vytvoˇren´a polymorfn´ı aplikace bude distribuov´ana v r˚ uzn´ ym verz´ıch rozliˇsen´ ych poskytnut´ ymi pr´avy. Nebezpeˇc´ım je i moˇznost podvrhnut´ı (respektive zamˇenˇen´ı) DEX souboru. K tomu by mohlo doj´ıt v momentˇe stahov´an´ı DEX souboru ze serveru. Soubor by n´aˇ slednˇe mohl zneuˇz´ıt pr´av poskytnut´ ych aplikaci a tak zp˚ usobit ˇskody. Skody by mohly b´ yt zp˚ usobeny t´ım, ˇze v t´eto knihovnˇe m˚ uˇze b´ yt um´ıstˇen ˇskodliv´ y ˇci jinak nebezpeˇcn´ y k´od. Tento k´od by mohl napˇr´ıklad poˇskodit zaˇr´ızen´ı ˇci data na nˇem uloˇzen´a. V jin´em pˇr´ıpadˇe by mohl data ze zaˇr´ızen´ı poskytovat tˇret´ım osob´am. Ide´aln´ım ˇreˇsen´ım problematiky bezpeˇcnosti v polymorfn´ı aplikaci zm´ınˇen´eho probl´emu by bylo zaveden´ı tzv. elektronick´eho podpisu soubor˚ u (nˇekdy t´eˇz oznaˇcovan´eho jako digit´aln´ı podpis“). Ten by zaruˇcoval jednoznaˇcnost a pravost soubor˚ u ” z´ısk´avan´ ych z vnˇejˇs´ıch zdroj˚ u“. Ze stejn´eho d˚ uvodu by bylo dobr´e zabezpeˇcit XML ” soubor slouˇz´ıc´ı pro popis generovan´e aplikace, kter´ y by byl uloˇzen na serveru (respektive jeho u ´loˇziˇsti). Mohlo by totiˇz doj´ıt k tomu, ˇze uˇzivatel by poˇzadoval urˇcit´e XML popisuj´ıc´ı generovanou aplikaci, avˇsak u ´toˇcn´ık by mohl nam´ısto odpovˇedi s p˚ uvodn´ım origin´aln´ım XML souborem poslat zpˇet do polymorfn´ı aplikace podvrhnut´ y soubor. Ten by se mohl z pohledu uˇzivatele tv´aˇrit jako p˚ uvodn´ı aplikace, avˇsak mohl by v popisech ovl´adac´ıch prvk˚ u odkazovat na nebezpeˇcn´e zdroje RPC i DEX. V´ıce o digit´aln´ıch podpisech soubor˚ u viz [Ber03]. Dalˇs´ı moˇznost´ı zabezpeˇcen´ı je pouˇzit´ı ˇsifrov´an´ı. To by zabezpeˇcilo, ˇze XML a DEX soubory nebude moˇzno zamˇenit za jejich obdoby obsahuj´ıc´ı ˇskodliv´ y k´od nebo jinou formou nebezpeˇcn´ y obsah. Druhou kladnou vlastnost´ı t´eto varianty je 48
Bezpeˇcnost polymorfn´ı aplikace
Moˇznosti ˇsifrov´an´ı
to, ˇze zaˇsifrovan´ y soubor nen´ı moˇzno jednoduch´ ym zp˚ usobem bez znalosti deˇsifrovac´ıho algoritmu a kl´ıˇce pro deˇsifrov´an´ı a ˇsifrov´an´ı zneuˇz´ıt ˇci pˇreˇc´ıst. Ochrana proti pˇreˇcten´ı tohoto souboru by byla vhodn´a pro vyuˇzit´ı polymorfn´ı aplikace napˇr´ıklad pro bankovnictv´ı a dalˇs´ı podobn´e u ´ˇcely. U tˇechto aplikac´ı totiˇz m˚ uˇze b´ yt nutn´e distribuovat k´od v ˇsifrovan´e podobˇe, aby byl ochr´anˇen jeho obsah, ve kter´em se mohou nach´azet d˚ uvˇern´e informace, ˇci zdrojov´ y k´od, kter´ y je nutno nˇejak´ ym zp˚ usobem chr´anit. Pro realizaci zabezpeˇcen´ı polymorfn´ı aplikace byla zvolena varianta s pouˇzit´ım ˇsifrov´an´ı.
8.2
Moˇ znosti ˇ sifrov´ an´ı
ˇ Sifrov´ an´ı, kter´e lze pouˇz´ıt pro zabezpeˇcen´ı dat se d´a obecnˇe rozdˇelit na dva z´akladn´ı druhy: • Symetrick´e • Asymetrick´e
8.2.1
Symetrick´ eˇ sifrov´ an´ı
Symetrick´e ˇsifrov´an´ı je zaloˇzeno na principu jednoho stejn´eho kl´ıˇce pro ˇsifrov´an´ı a deˇsifrov´an´ı. Slab´e m´ısto symetrick´eho ˇsifrov´an´ı spoˇc´ıv´a v tom, ˇze je tˇreba pro dek´odov´an´ı z´ıskat kl´ıˇc, kter´ ym byly data k´odov´any. K tomu je tˇreba pouˇz´ıt nˇejak´ y bezpeˇcn´ y zp˚ usob pˇrenosu k´odovac´ıho/dek´odovac´ıho kl´ıˇce. Pokud vˇsak existuje, je ˇcasto jednoduˇsˇs´ı poslat data pˇr´ımo za pouˇzit´ı tohoto pˇrenosu. Symetrick´e ˇsifrov´an´ı je mnohem jednoduˇsˇs´ı neˇz asymetrick´e, pro jeho zpracov´an´ı obecnˇe staˇc´ı menˇs´ı v´ ykon neˇz na asymetrick´e ˇsifrov´an´ı. Symetrick´e ˇsifrov´an´ı se d´a dobˇre pouˇz´ıt v pˇr´ıpadˇe, ˇze odes´ılatel a pˇr´ıjemce dat si pˇredem dohodli, jak´ y kl´ıˇc pro ˇsifrov´an´ı pouˇzij´ı. Pˇredstaviteli symetrick´eho ˇsifrov´an´ı jsou DES ( Data Encryption Standard“), ” ˇ Triple DES a AES ( Advanced Encryption Standard“ neboli tak´e Rijndael ). Si” frov´an´ı AES je bezpeˇcnˇejˇs´ı neˇz DES a Triple DES. V´ıce o historii, vlastnostech a principu AES v [Dol01]. 49
Bezpeˇcnost polymorfn´ı aplikace
Moˇznosti ˇsifrov´an´ı
Symetrick´e ˇsifrov´an´ı lze d´ale dˇelit na tyto typy: • Blokov´e ˇsifry - Blokov´e ˇsifry pracuj´ı s pevn´ ym poˇctem bit˚ u. Tyto bloky jsou pomoc´ı kl´ıˇce zaˇsifrov´any a v´ ystupem je pˇr´ısluˇsn´a ˇc´ast ˇsifrovan´eho textu. Nˇekter´e algoritmy prov´adˇej´ı nˇekolikan´asobn´e ˇsifrov´an´ı bloku dokola, aby se zv´ yˇsila bezpeˇcnost. Blokov´e ˇsifry jsou na ˇsifrov´an´ı dat v praxi vyuˇz´ıv´any ˇcastˇeji neˇz proudov´e (ty budou pops´any d´ale). Mezi blokov´e ˇsifry patˇr´ı napˇr´ıklad algoritmy DES, AES, IDEA, Blowfish a jin´e. • Proudov´e ˇsifry - Proudov´e ˇsifry jsou rychlejˇs´ı neˇz blokov´e. Vhodnˇejˇs´ı jsou tam, kde nen´ı moˇzn´e vyuˇz´ıvat buffer. Typick´ ym pˇr´ıkladem je telekomunikace a jin´e real-time spojen´ı, kde nen´ı vhodn´e ˇcekat na naplnˇen´ı bufferu, ale je tˇreba data ˇsifrovat ihned. Tyto ˇsifry jsou zaloˇzeny na ˇsifrov´an´ı kaˇzd´eho znaku otevˇren´eho textu zvl´aˇst’. Mezi z´astupce proudov´ ych ˇsifer patˇr´ı algoritmy RC4, FISH, Helix, SEAL, WAKE a dalˇs´ı.
8.2.2
Asymetrick´ eˇ sifrov´ an´ı
Asymetrick´e ˇsifrov´an´ı vyuˇz´ıv´a toho, ˇze kl´ıˇc pouˇzit´ y pro ˇsifrov´an´ı dat je jin´ y neˇz kl´ıˇc pro deˇsifrov´an´ı. Prvn´ım typem kl´ıˇce je tzv. veˇrejn´ y“ kl´ıˇc. Tento kl´ıˇc dok´aˇze deˇsifrovat zpr´avy za” ˇsifrovan´e druh´ ym typem kl´ıˇce (tzv. soukrom´ ym“, priv´atn´ım“ nebo-li tak´e tajn´ ym“ ” ” ” kl´ıˇcem). Odes´ılatel zpr´avy provede zaˇsifrov´an´ı zpr´avy veˇrejn´ ym kl´ıˇcem adres´ata. Ten po pˇrijet´ı t´eto zaˇsifrovan´e zpr´avy provede deˇsifrov´an´ı sv´ ym priv´atn´ım kl´ıˇcem. Nejrozˇs´ıˇrenˇejˇs´ım typem tohoto ˇsifrov´an´ı je RSA. Tento typ pouˇz´ıv´a modul´arn´ı aritmetiku (neboli matematikou zab´ yvaj´ıc´ı se zbytky po dˇelen´ı cel´ ych ˇc´ısel). Citace pro tuto ˇca´st textu byly pouˇzity z [Mun07], kde se lze dozvˇedˇet v´ıce o principech a vlastnostech ˇsifrov´an´ı.
50
Bezpeˇcnost polymorfn´ı aplikace
8.2.3
Moˇznosti ˇsifrov´an´ı
AES pro ˇ sifrov´ an´ı v r´ amci polymorfn´ı aplikace
Tento ˇsifrovac´ı algoritmus byl pro polymorfn´ı aplikaci navrhnut a pouˇzit z d˚ uvodu sv´e pomˇernˇe velk´e bezpeˇcnosti a rychlosti. Hlavn´ım c´ılem t´eto ˇsifry bylo ˇreˇsit nedostatky DES ˇsifrov´an´ı. Oproti Triple DES a DES je rychlejˇs´ı a bezpeˇcnˇejˇs´ı. AES je symetrickou blokovou ˇsifrou, kter´a vyuˇz´ıv´a d´elku kl´ıˇce 128, 192 nebo 256 bit˚ u. O vzniku a pouˇzit´ı algoritmu AES se lze dozvˇedˇet v [Dol01]. Pro polymorfn´ı aplikaci je ˇsifrov´an´ı AES vhodn´e na zabezpeˇcen´ı soubor˚ u z´ısk´avan´ ych aplikac´ı ze zdroj˚ u, kter´e nemus´ı b´ yt bezpeˇcn´e. T´ım je myˇsleno, ˇze pˇrenos dat z nich a na nˇe je moˇzno naruˇsit (z´amˇenou ˇci poˇskozen´ım pˇren´aˇsen´ ych dat). U ˇsifrov´an´ı AES pouˇzit´eho v polymorfn´ı aplikaci byla experimentov´an´ım nalezena v´ yhoda. Ta spoˇc´ıv´a v tom, ˇze pokud pˇri pˇren´aˇsen´ı zaˇsifrovan´ ych dat dojde ke zmˇenˇe byt’ jedin´eho bytu, tak je dan´ y soubor nedeˇsifrovateln´ y. K tomuto probl´emu by mohlo doj´ıt, pokud by u ´toˇcn´ık“ chtˇel zmˇenit obsah dat. Aby bylo moˇzn´e efektivnˇe pro” lomit toto zabezpeˇcen´ı, musel by u ´toˇcn´ık zn´at heslo, kter´ ym byla data ˇsifrov´ana, a pouˇzit´ y algoritmus ˇsifrov´an´ı. Vyuˇzit´ı ˇsifrov´an´ı AES ve vytvoˇren´e polymorfn´ı aplikaci je takov´e, ˇze v´ yvoj´aˇr m´a moˇznost zaˇsifrovat pomoc´ı AES XML soubor pro popis generovan´e aplikace. Stejn´ ym zp˚ usobem je moˇzno ˇsifrovat i DEX knihovny pouˇzit´e pro polymorfn´ı aplikaci. K proveden´ı t´eto akce staˇc´ı zadat v hlavn´ı aktivitˇe pˇres tlaˇc´ıtko Menu poloˇzku Nastaven´ı hesla pro ˇsifrov´an´ı a zde nastavit heslo pro ˇsifrov´an´ı. Pro zv´ yˇsen´ı bezpeˇcnosti je nutn´e, aby toto heslo mˇelo 16 znak˚ u (jinak bude pouˇzito pˇrednastaven´e heslo fakultafavzcuplz“). N´aslednˇe pak zadat adresu souboru, kter´ y chce v´ yvoj´aˇr ” zaˇsifrovat do textov´eho pole, a pˇres Menu zvolit poloˇzku Vytvoˇrit ˇsifrovan´y soubor. Proveden´ım t´eto akce se dan´ y soubor pˇreˇcte ze zadan´e adresy a zaˇsifruje do souboru ve vnitˇrn´ı pamˇeti. V pˇr´ıpadˇe pˇr´ıtomnosti SD karty je zaˇsifrovan´ y soubor pˇrednostnˇe uloˇzen na ni. Odtud si ho v´ yvoj´aˇr m˚ uˇze st´ahnout a uloˇzit na poˇzadovan´ y server, odkud ho budou moci vyuˇz´ıvat i dalˇs´ı zaˇr´ızen´ı prostˇrednictv´ım polymorfn´ı aplikace pro svou ˇcinnost. V t´eto ˇca´sti bylo implementov´ano zjednoduˇsen´ı v podobˇe moˇznosti nechat si zaˇsifrovan´ y soubor zaslat na email (v pˇr´ıpadˇe, ˇze je na dan´em zaˇr´ızen´ı odpov´ıdaj´ıc´ı aplikace pro odes´ıl´an´ı elektronick´e poˇsty).
51
Bezpeˇcnost polymorfn´ı aplikace
Moˇznosti ˇsifrov´an´ı
Pro ˇsifrov´an´ı soubor˚ u je potˇreba nejdˇr´ıve tento soubor z dan´e adresy z´ıskat. To je v polymorfn´ı aplikaci ˇreˇseno n´asleduj´ıc´ım zp˚ usobem: DefaultHttpClient hc = new DefaultHttpClient(); ResponseHandler <String> res = new BasicResponseHandler(); HttpPost postMethod = new HttpPost(sUrl[0].toString()); String response = hc.execute(postMethod,res); String pass = readString(MainActivity.this, "password", "fakultafavzcuplz"); byte[] crypted = encrypt(response, pass);
Metoda readString v t´eto uk´azce reprezentuje zjiˇstˇen´ı hesla, uloˇzen´eho v tzv. sd´ılen´ ych preferenc´ıch“. Po zjiˇstˇen´ı tohoto hesla dojde k zaˇsifrov´an´ı textu souboru ” (v uk´azce z´ısk´an do promˇenn´e response). V´ ysledek je uloˇzen jako byte[] s n´azvem encrypted. Uk´azka k´odu pouˇzit´eho pro ˇsifrov´an´ı textu je vidˇet v n´asleduj´ıc´ım k´odu: private static byte[] encrypt(String text, String pass) throws Exception { byte[] keyStart = pass.getBytes(); KeyGenerator kgen = KeyGenerator.getInstance("AES"); SecureRandom sr = SecureRandom.getInstance("SHA1PRNG"); sr.setSeed(keyStart); kgen.init(128, sr); // 192 and 256 bits may not be available SecretKey skey = kgen.generateKey(); byte[] key = skey.getEncoded(); SecretKeySpec skeySpec = new SecretKeySpec(key, "AES"); Cipher cipher = Cipher.getInstance("AES"); cipher.init(Cipher.ENCRYPT_MODE, skeySpec); byte[] encrypted = cipher.doFinal(text.getBytes()); return encrypted; } 52
Bezpeˇcnost polymorfn´ı aplikace
Moˇznosti ˇsifrov´an´ı
Deˇsifrov´an´ı je prov´adˇeno obdobnˇe jako ˇsifrov´an´ı. Vstupem je pole byte[], obsahuj´ıc´ı data ˇsifrovan´eho souboru. V´ ysledkem je ˇretˇezec (decrypted) obsahuj´ıc´ı p˚ uvodn´ı text. Deˇsifrov´an´ı je vidˇet v n´asleduj´ıc´ı uk´azce zdrojov´eho k´odu polymorfn´ı aplikace:
private static byte[] decrypt(byte[] encrypted, String pass) throws Exception { byte[] keyStart = pass.getBytes("UTF-8"); KeyGenerator kgen = KeyGenerator.getInstance("AES"); SecureRandom sr = SecureRandom.getInstance("SHA1PRNG"); sr.setSeed(keyStart); kgen.init(128, sr); // 192 and 256 bits may not be available SecretKey skey = kgen.generateKey(); byte[] key = skey.getEncoded(); SecretKeySpec skeySpec = new SecretKeySpec(key, "AES"); Cipher cipher = Cipher.getInstance("AES"); cipher.init(Cipher.DECRYPT_MODE, skeySpec); byte[] decrypted = cipher.doFinal(encrypted); return decrypted; }
Tento zp˚ usob lze pouˇz´ıt pouze v pˇr´ıpadˇe, ˇze ˇsifrovan´e soubory, kter´e byly zaˇsifrov´any pod syst´emem Android, budou deˇsifrov´any znovu na tomto syst´emu. V pˇr´ıpadˇe deˇsifrov´an´ı dat na jin´em syst´emu neˇz byla data ˇsifrov´ana, je moˇznost, ˇze vznikne probl´em s t´ım, ˇze data nep˚ ujdou spr´avnˇe deˇsifrovat. K zm´ınˇen´emu probl´emu m˚ uˇze doj´ıt z d˚ uvodu ˇspatn´eho nastaven´ı ˇsifrovac´ıho sch´ematu ˇci z d˚ uvodu generov´an´ı jin´eho deˇsifrovac´ıho kl´ıˇce (to m˚ uˇze b´ yt zp˚ usobeno pouˇzit´ım jin´e platformy). K tomu by mohlo doj´ıt, pokud by DEX knihovna zaˇrizovala komunikaci se serverem, kter´ y bˇeˇz´ı napˇr´ıklad na syst´emu Windows.
53
Bezpeˇcnost polymorfn´ı aplikace
Moˇznosti ˇsifrov´an´ı
V popsan´em pˇr´ıpadˇe lze pouˇz´ıt pˇr´ımo nastaven´ı 16 byt˚ u (128 bit˚ u) pro nastaven´ı kl´ıˇce. To by vypadalo napˇr´ıklad n´asledovnˇe: private static byte[] encrypt(String text, String pass) throws Exception { byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; SecretKeySpec skeySpec = new SecretKeySpec(keyBytes, "AES"); Cipher cipher = Cipher.getInstance("AES"); cipher.init(Cipher.ENCRYPT_MODE, skeySpec); byte[] encrypted = cipher.doFinal(text.getBytes()); return encrypted; } Obdobnˇe by se tak deˇsifrovala data i na stranˇe serveru. Soubory zaˇsifrovan´e pomoc´ı zm´ınˇen´eho k´odu dost´avaj´ı novou pˇr´ıponu konˇc´ıc´ı p´ısmenem c“. XML soubor, kter´ y bude takto zaˇsifrov´an, dostane m´ısto sv´e p˚ u” vodn´ı pˇr´ıpony novou pˇr´ıponu .xmlc“. To sam´e plat´ı i pro zaˇsifrov´an´ı DEX souboru ” reprezentovan´eho jako .jar“, kter´ y po zaˇsifrov´an´ı dostane pˇr´ıponu .jarc“. ” ” Polymorfn´ı aplikace pak vˇzdy, kdyˇz pˇri sv´e pr´aci naraz´ı na typ souboru .xmlc“ ” nebo .jarc“, vyuˇzije ˇsifrov´an´ı s heslem nastaven´ ym v jiˇz zm´ınˇen´e poloˇzce v Menu. ” Bez spr´avnˇe nastaven´eho hesla nebude moˇzno tyto soubory deˇsifrovat. Pro pˇr´ıpad, ˇze by u ´toˇcn´ık mˇel pˇr´ıstup k pamˇeti dan´eho zaˇr´ızen´ı, jsou soubory typu .jarc“ v pamˇeti uchov´av´any v ˇsifrovan´e podobˇe a v neˇsifrovan´e podobˇe se vyu” ˇz´ıvaj´ı pouze pro intern´ı ˇcinnost, jinak se v neˇsifrovan´e podobˇe do pamˇeti neukl´adaj´ı. T´ım je u ´toˇcn´ıkovi zabr´anˇeno podvrˇzen´ı dan´eho souboru v pˇr´ıpadˇe jeho zamˇenˇen´ı v pamˇeti za jin´ y (respektive nebezpeˇcn´ y) soubor. Pro ˇsifrovan´e komunikace se serverem lze vyuˇz´ıt vlastn´ı DEX knihovny, ve kter´e bude ˇsifrov´an´ı vytvoˇreno v´ yvoj´aˇrem. Zde vˇsak pˇri vytv´aˇren´ı polymorfn´ı aplikace 54
Bezpeˇcnost polymorfn´ı aplikace
Moˇznosti ˇsifrov´an´ı
nast´av´a probl´em s t´ım, ˇze DEX knihovna sama o sobˇe nem´a moˇznost komunikovat s uˇzivatelsk´ ym rozhran´ım a vyuˇz´ıvat jeho moˇznost´ı. Jedinou moˇznost´ı, kterou m´a DEX pro komunikaci s uˇzivatelsk´ ym rozhran´ım k dispozici, je pˇres n´avratov´e hodnoty procedur (dle n´avrhu aplikace). T´ım se sice zabezpeˇc´ı u ´pravy uˇzivatelsk´eho rozhran´ı, kter´e by mohl u ´toˇcn´ık prov´est, avˇsak probl´em spoˇc´ıv´a v s´ıt’ov´e pr´aci uvnitˇr samotn´e DEX knihovny. Podle pravidel v´ yvoje aplikac´ı pro Android je nutn´e vytv´aˇret pro s´ıt’ovou komunikaci nov´e vl´akno a nebo vyuˇz´ıvat prostˇredku pro asynchronn´ı ˇcinnosti (tzv. AsyncTask). Toto ˇreˇsen´ı je nutn´e z d˚ uvodu, aby hlavn´ı vl´akno, kter´e by mˇelo prov´adˇet s´ıt’ov´e operace, nebylo tˇemito operacemi zdrˇzov´ano na u ´kor plynulosti bˇehu aplikace (respektive hlavn´ı vl´akno nesm´ı obsahovat s´ıt’ov´e operace). Pokud je vˇsak v DEX knihovnˇe vytvoˇrena procedura, kter´a m´a komunikovat s´ıt’ov´ ymi prostˇredky (tedy komunikaˇcn´ı ˇca´st je um´ıstˇena v AsyncTask), tak operace DEX samotn´eho skonˇc´ı dˇr´ıve, neˇz staˇc´ı AsyncTask operace zajiˇst’uj´ıc´ı ˇsifrovanou komunikaci pˇredat n´avratovou hodnotu. Jinak ˇreˇceno takov´ato komunikace se pak tv´aˇr´ı pro klienta jako proveden´a, avˇsak v´ ysledky komunikace se uˇzivatel jiˇz nedozv´ı. K tomu byla v aktivitˇe pro generovan´e aplikace zavedena metoda oznaˇcen´a jako makeText(String text), kter´a zaˇrizuje vypisov´an´ı informaˇcn´ıch text˚ u na obrazovku (v r´amci hlavn´ıho vl´akna).
55
9 Vytvoˇren´e uk´azkov´e ”generovan´e aplikace“
Pro ovˇeˇren´ı funkcionality polymorfn´ı aplikace byly vytvoˇreny r˚ uzn´e uk´azkov´e generovan´e aplikace. Tyto generovan´e aplikace maj´ı za u ´kol potvrdit spr´avnost myˇslenky polymorfn´ı aplikace a uk´azat cestu, kterou by mohlo b´ yt pokraˇcov´ano v rozvoji realizovan´e myˇslenky t´eto polymorfn´ı apliace. Pro spuˇstˇen´ı poˇzadnovan´e generovan´e aplikace prostˇrednictv´ım polymorfn´ı aplikace je potˇreba n´asleduj´ıc´ı: • Polymorfn´ı aplikace mus´ı b´ yt nasazena na zaˇr´ızen´ı se syst´emem Android (viz pˇr´ıloha C). • XML popis generovan´e aplikace mus´ı b´ yt d´an k dispozici serverem (resp. tento soubor mus´ı b´ yt s´ıt’ovˇe dostupn´ y). • V pˇr´ıpadˇe, ˇze generovan´a aplikace vyuˇz´ıv´a RPC, tak poˇzadovan´ y RPC server mus´ı b´ yt spuˇstˇen´ y a s´ıt’ovˇe ze zaˇr´ızen´ı dostupn´ y (viz pˇr´ıloha D). • V pˇr´ıpadˇe, ˇze generovan´a aplikace vyuˇz´ıv´a DEX, tak vˇsechny poˇzadovan´e knihovny mus´ı b´ yt s´ıt’ovˇe ze zaˇr´ızen´ı dostupn´e. V dalˇs´ıch podkapitol´ach jsou pops´any jednotlivˇe vˇsechny vytvoˇren´e generovan´e aplikace.
9.1 9.1.1
Grafick´ a kalkulaˇ cka Z´ akladn´ı myˇ slenka
Aplikace byla navrˇzena na z´akladˇe myˇslenky vytvoˇren´ı generovan´e aplikace (pro polymorfn´ı aplikaci), kter´a bude umˇet vykreslovat dle uˇzivatelem zadan´ ych parametr˚ u grafov´e pr˚ ubˇehy.
56
Vytvoˇren´e uk´azkov´e generovan´e aplikace“ ”
9.1.2
Grafick´a kalkulaˇcka
Realizace
Aplikace se skl´ad´a ze zad´avac´ı a zobrazovac´ı ˇc´asti. V zad´avac´ı ˇca´sti m˚ uˇze uˇzivatel nastavit Typ funkce, kterou chce vykreslit a k n´ı poˇca´tek a konec vykreslovan´eho intervalu. Pro uk´azkovou generovanou aplikaci Grafick´a kalkulaˇcka“ byly jako vzo” rov´e implementov´any funkce sinus a cosinus. Generovan´a aplikace Grafick´a kalkulaˇcka“ byla vytvoˇrena ve dvou variant´ach. ” Prvn´ı varianta byla vytvoˇrena za pouˇzit´ı RPC. Vyuˇz´ıv´a vol´an´ı vzd´alen´ ych procedur ve formˇe, ve kter´e byla tato varianta popisov´ana v pˇredchoz´ıch kapitol´ach. Samotn´e zpracov´an´ı k´odu na serveru je vidˇet v n´asleduj´ıc´ı uk´azce. Na serveru je pˇripravena metoda, kter´a zabezpeˇcuje vytvoˇren´ı dat grafu:
public Object[] grahpsSinCos (Object[] input) { inputArray = new String[input.length]; outputArray = new String[3]; String outputText = ""; double granularity = 0.1; double zacatekIntervalu = 0; double konecIntervalu = 0;
Po inicializaci pˇri spuˇstˇen´ı metody je tˇreba extrahovat vstupn´ı parametry, kter´e byly t´eto metodˇe pˇred´any pˇri jej´ım vol´an´ı:
for (int i = 0; i < inputArray.length; i++) { inputArray[i] = (String) input[i]; } try { System.out.println(inputArray[1]); System.out.println(inputArray[2]); inputArray[1].replace(’,’, ’.’); inputArray[2].replace(’,’, ’.’); zacatekIntervalu = Double.parseDouble(inputArray[1]); konecIntervalu = Double.parseDouble(inputArray[2]); 57
Dalˇs´ım krokem je samotn´ y v´ ypoˇcet dat pro graf. V tomto pˇr´ıpadˇe jde o vytv´aˇren´ı pˇr´ımek po tak jemn´em intervalu, ˇze se uˇzivateli bude v´ ysledn´ y pr˚ ubˇeh jevit jako plynul´a sinusoida ˇci kosinusoida.
double pocet = ((konecIntervalu - zacatekIntervalu) / jemnost) + 1; int pocetZaokr = (int)Math.round(pocet); outputArray[0] = "0"; outputArray[1] = "Graf vykreslen"; if (inputArray[0].trim().equals("sin")) { System.out.println("Zvolen sinus"); for (int i = 0; i < (pocetZaokr * 2); i += 2) { outputText += (i / 2) * jemnost + zacatekIntervalu + ";"; outputText += Math.sin((i / 2) * jemnost + zacatekIntervalu) + ";"; } outputText.substring(0, outputText.length() - 2); outputArray[2] = "Sinus@" + outputText; } else if (inputArray[0].trim().equals("cos")) { System.out.println("Zvolen cosinus"); for (int i = 0; i < (pocetZaokr * 2); i += 2) { outputText += (i / 2) * jemnost + ";"; outputText += Math.cos((i / 2) * jemnost) + ";"; } outputText.substring(0, outputText.length() - 2); outputArray[2] = "Cosinus@" + outputText; } else { System.out.println("Nezvoleno nic!"); 58
Vytvoˇren´e uk´azkov´e generovan´e aplikace“ ”
Grafick´a kalkulaˇcka
outputArray = new String[2]; outputArray[0] = "-1"; outputArray[1] = "Nezvoleno nic!"; } Object[] outputObject = (Object[])outputArray; return outputObject; } Zdrojov´ y k´od je implementac´ı n´avrhu popsan´eho v kapitole 7.5.1 (ˇc´asti o popisu graf˚ u polymorfn´ı aplikace). Obdobn´ ym zp˚ usobem funguje i varianta pro DEX, kter´a obsahuje v DEX knihovnˇe prakticky totoˇzn´ y zdrojov´ y k´od. Na uk´azce je vidˇet, ˇze pro polymorfn´ı aplikaci lze vytvoˇrit generovan´e aplikace, kter´e zpracov´avaj´ı napˇr´ıklad v´ ypoˇctov´e u ´lohy. Graf generovan´e aplikace m˚ uˇze b´ yt vyuˇzit pˇri tvorbˇe aplikac´ı zobrazuj´ıc´ıch statistick´e hodnoty ˇci r˚ uzn´a mˇeˇren´ı (napˇr´ıklad vyt´ıˇzen´ı serveru, aplikace pro zobrazov´an´ı meteorologick´ ych pr˚ ubˇeh˚ u atd.).
Obr´azek 9.1: Uk´azka generovan´e aktivity Grafick´a kalkulaˇcka“ spuˇstˇen´e v emul´a” toru. Uk´azka, jak vypad´a generovan´a aplikace je vidˇet na obr´azku 9.1. 59
Vytvoˇren´e uk´azkov´e generovan´e aplikace“ ”
9.1.3
D´alkov´y multimedi´aln´ı ovladaˇc
Varianty generovan´ e aplikace
Varianta RPC se d´a vyuˇz´ıt v pˇr´ıpadech, kde data pro tuto aplikaci nelze z´ıskat jinak neˇz ze vzd´alen´eho serveru (ˇci jin´eho m´ısta v s´ıti). Dalˇs´ı moˇznost´ı jsou v´ ypoˇcetnˇe n´aroˇcn´e u ´lohy, kter´e by nebylo moˇzn´e zpracov´avat na mobiln´ım zaˇr´ızen´ı. D˚ uvodem by mohla b´ yt zv´ yˇsen´a spotˇreba energie, n´ızk´ y v´ ypoˇcetn´ı v´ ykon ˇci hardwarov´e omezen´ı zaˇr´ızen´ı. Varianta DEX by se mohla vyuˇz´ıt v pˇr´ıpadech, kdy by bylo nutn´e (napˇr. v´ ypoˇcetn´ı) operace prov´adˇet bez dostupnosti s´ıt’ov´eho pˇripojen´ı. Jedn´ım z dalˇs´ıch faktor˚ u pro pouˇzit´ı DEX je tak´e to, ˇze by pˇrenos dat v pˇr´ıpadˇe RPC byl ˇcasovˇe (ˇci objemovˇe) n´aroˇcn´ y a nebo v pˇr´ıpadˇe, ˇze by data mohla b´ yt nˇejak´ ym zp˚ usobem zneuˇzita.
9.2 9.2.1
D´ alkov´ y multimedi´ aln´ı ovladaˇ c Z´ akladn´ı myˇ slenka
Tato generovan´a aplikace vytvoˇren´a pro polymorfn´ı aplikaci je zaloˇzena na myˇslence ovl´ad´an´ı jin´ ych zaˇr´ızen´ı z polymorfn´ı aplikace a t´ım rozˇs´ıˇren´ı jej´ıch moˇznost´ı. Pro uk´azku vzd´alen´eho ovl´ad´an´ı byla pouˇzita aplikace VLC media player 2.0.3 Twoflower“ (v´ıce viz [Vlc12]). Zm´ınˇen´a aplikace slouˇz´ı jako multimedi´aln´ı audio/vi” deo pˇrehr´avaˇc.
9.2.2
Realizace
Generovan´a aplikace D´alkov´ y multimedi´aln´ı ovladaˇc“ byla navrˇzena tak, aby jej´ı ” pomoc´ı bylo moˇzno vyuˇz´ıvat co nejvˇetˇs´ı mnoˇzstv´ı funkˇcnost´ı ovl´adan´eho programu VLC media player. Z pohledu grafick´eho uˇzivatelsk´eho rozhran´ı se d´a aplikace rozdˇelit na dva bloky. Prvn´ım blokem jsou standardn´ı ovl´adac´ı prvky, kter´e lze naj´ıt u jak´ehokoli ovladaˇce podobn´ ych program˚ u (i zaˇr´ızen´ı). Zde se nach´azej´ı ovl´adac´ı prvky pro spuˇstˇen´ı, pozastaven´ı a u ´pln´e zastaven´ı ovl´adan´eho pˇrehr´avaˇce. D´ale lze pˇrep´ınat skladby uloˇzen´e v seznamu skladeb (tzv. playlistu“). Posledn´ım ovl´adac´ım prvkem t´eto ˇca´sti ” je vypnut´ı pˇrehr´avaˇce. 60
Vytvoˇren´e uk´azkov´e generovan´e aplikace“ ”
D´alkov´y multimedi´aln´ı ovladaˇc
Druh´ ym blokem uˇzivatelsk´eho rozhran´ı je ovl´ad´an´ı pomoc´ı konzolov´ ych pˇr´ıkaz˚ u. Jde tedy o to, ˇze uˇzivatel nemus´ı m´ıt v uˇzivatelsk´em rozhran´ı vˇsechny moˇzn´e ovl´adac´ı prvky, ale pouze ty, kter´e vyuˇz´ıv´a nejˇcastˇeji. V pˇr´ıpadˇe, ˇze by uˇzivatel chtˇel pˇri pˇrehr´av´an´ı nˇejak´eho audio/video souboru ztlumit zvuk, tak m´ısto hled´an´ı ovl´adac´ıho prvku staˇc´ı do konzolov´eho okna na spodn´ı ˇc´asti uˇzivatelsk´eho rozhran´ı napsat pˇr´ıkaz mute“ (teda v pˇrekladu do ˇcesk´eho ja” zyka ztlumit“). Po zad´an´ı ˇr´ıd´ıc´ıho pˇr´ıkazu dojde k okamˇzit´emu odesl´an´ı tohoto ” pˇr´ıkazu na server, kde je d´ale zpracov´an. Pokud na serveru nebˇeˇz´ı poˇzadovan´a obsluˇzn´a procedura, je o tom uˇzivatel informov´an pomoc´ı (doˇcasn´eho) textov´eho pole na obrazovce. Za pˇredpokladu, ˇze na server pˇr´ıkaz doraz´ı a server tento pˇr´ıkaz rozpozn´a, dojde k odesl´an´ı tohoto pˇr´ıkazu pomoc´ı tzv. telnet“ (tedy protokolu pro vzd´alen´ y pˇr´ıstup) ” na port, se kter´ ym byl program VLC media player spuˇstˇen. V´ıce o telnetu pouˇzit´eho v t´eto pr´aci viz [Apa13] Pro spuˇstˇen´ı programu VLC media player pˇripraven´eho k d´alkov´emu ovl´ad´an´ı pˇres zadan´ y port je potˇreba pˇrehr´avaˇc spustit n´asleduj´ıc´ım pˇr´ıkazem: vlc --rc-host=localhost:1112
Uveden´ y pˇr´ıkaz spust´ı VLC media player s otevˇren´ ym s´ıt’ov´ ym portem 1112. Na zm´ınˇen´ y port lze n´aslednˇe ze serveru zas´ılat pˇr´ıkazy. Port je pro uk´azkovou generovanou aplikaci napevno nastaven na hodnotu 1112. Odes´ıl´an´ı pˇr´ıkaz˚ u ze serveru na zadan´ y port VLC media playeru pak vypad´a napˇr´ıklad dle n´asleduj´ıc´ıho uk´azkov´eho zdrojov´eho k´odu pro pˇr´ıkaz pause“: ” public Object[] pause (Object[] input) { inputArray = new String[input.length]; outputArray = new String[2]; String command = "pause"; try { tl = new TelnetClient(); tl.connect("localhost", 1112); if(tl.isConnected()) { outputArray = new String[2]; } else { 61
Vytvoˇren´a generovan´a aplikace ukazuje jednu z moˇznost´ı, jak lze vyuˇz´ıt zpracov´an´ı vzd´alen´eho k´odu. Po u ´pravˇe XML popisu aplikace a zmˇenˇe serverov´e ˇca´sti by mohla b´ yt napˇr´ıklad pouˇzita ve variant´ach vzd´alen´eho syst´emov´eho pˇr´ıkazov´eho ˇra´dku ˇci jin´ ym obdobn´ ym zp˚ usobem. V p˚ uvodn´ım n´avrhu t´eto generovan´e aplikace byla uvaˇzov´ana varianta vracet ze serveru zpˇet zpr´avu o aktu´alnˇe pˇrehr´avan´ ych souborech. Dle neofici´aln´ıch n´avod˚ u tato moˇznost teoreticky“ existuje, avˇsak po s´erii test˚ u bylo zjiˇstˇeno, ˇze zkouˇsen´a ” verze programu VLC media player nevrac´ı zpˇet prostˇrednictv´ım telnet poˇzadovan´e zpr´avy (o aktu´aln´ım stavu a pˇrehr´av´an´ı). To vˇsak nem´a vliv na ovˇeˇren´ı funkcionality 62
Vytvoˇren´e uk´azkov´e generovan´e aplikace“ ”
Zabezpeˇcen´e hlasovac´ı zaˇr´ızen´ı
realizovan´e polymorfn´ı aplikace. Pro tvorbu serverov´e ˇc´asti byl pouˇzit zdroj [Vid10].
Obr´azek 9.2: Uk´azka generovan´e aktivity D´alkov´ y multimedi´aln´ı ovladaˇc“ spuˇstˇen´e ” v emul´atoru. Uk´azka, jak vypad´a generovan´a aplikace je vidˇet na obr´azku 9.2.
9.3 9.3.1
Zabezpeˇ cen´ e hlasovac´ı zaˇ r´ızen´ı Z´ akladn´ı myˇ slenka
Generovan´a aplikace Zabezpeˇcen´e hlasovac´ı zaˇr´ızen´ı“ byla navrˇzena na prezentaci ” zabezpeˇcen´e komunikace s vyuˇzit´ım ˇsifrovac´ıho algoritmu AES popsan´eho v kapitole 8.2.3. Aplikace by se dala vyuˇz´ıt na odes´ıl´an´ı n´azor˚ u/dotaz˚ u student˚ u na urˇcitou t´ematiku bˇehem kon´an´ı semin´aˇr˚ u a pˇredn´aˇsek ˇci k obdobn´ ym u ´ˇcel˚ um.
63
Vytvoˇren´e uk´azkov´e generovan´e aplikace“ ”
Zabezpeˇcen´e hlasovac´ı zaˇr´ızen´ı
ˇ Cinnost t´eto aplikace je zaloˇzena na myˇslence pouˇzit´ı DEX varianty. DEX knihovna obsahuje proceduru, kter´a komunikuje se serverem jako v pˇr´ıpadˇe XML-RPC varianty. Hlavn´ı rozd´ıl spoˇc´ıv´a v tom, ˇze zat´ımco ve variantˇe XML-RPC se data pos´ılaj´ı v neˇsifrovan´e podobˇe, tato DEX knihovna pˇred samotn´ ym odesl´an´ım dat data zaˇsifruje pomoc´ı AES.
9.3.2
Realizace
Grafick´e uˇzivatelsk´e rozhran´ı t´eto generovan´e aplikace je zaloˇzeno na editovateln´em textov´em poli a jednom ovl´adac´ım prvku. Text, kter´ y je zad´an do zm´ınˇen´eho editovateln´eho pole je po aktivov´an´ı ovl´adac´ıho prvku (respektive tlaˇc´ıtka) standardnˇe pˇred´an DEX knihovnˇe. V t´eto DEX knihovnˇe je na zaˇsifrov´an´ı textu pouˇzito pˇripraven´e AES ˇsifrov´an´ı. D´ale je pak zkontrolov´ano pˇripojen´ı a zpr´ava pomoc´ı XML-RPC odesl´ana na server. Zde doch´az´ı k probl´emu zm´ınˇen´emu v kapitole 8.2.3. Ten spoˇc´ıv´a v tom, ˇze je nutn´e veˇskerou s´ıt’ovou komunikaci ˇreˇsit mimo hlavn´ı vl´akno aplikace. K ˇreˇsen´ı lze pouˇz´ıt bud’ vl´aken a nebo varianty, kter´a provede asynchronn´ı operace sama (jak jiˇz bylo zm´ınˇeno v pˇredeˇsl´ ych kapitol´ach). Oznaˇcuje se jako tzv. AsyncTask, neboli prostˇredek pro asynchronn´ı zpracov´an´ı k´odu. Je zaloˇzen na rozdˇelen´ı k´odu, kter´ y se m´a prov´adˇet paralelnˇe (v tomto pˇr´ıpadˇe s´ıt’ov´e operace). Ten je d´ale rozdˇelen na dvˇe ˇca´sti do tˇr´ıdy, kter´a rozˇsiˇruje tzv. AsyncTask. Zm´ınˇen´a tˇr´ıda vytv´aˇr´ı jako generick´ y typ, kde prvn´ım typem generika jsou vstupn´ı parametry, dalˇs´ım je stav pokroku ˇcinnosti a posledn´ım v´ ystupn´ı parametry (citace viz [Anw11]). Hlaviˇcka t´eto tˇr´ıdy je vidˇet v n´asleduj´ıc´ı uk´azce:
class TryResponse extends AsyncTask<String[], Integer, Integer>
Tato tˇr´ıda v sobˇe obsahuje v´ıce metod. Prvn´ı je ˇca´st k´odu, kter´a je urˇcena pro s´ıt’ovou komunikaci a je uloˇzena v metodˇe doInBackground. Metoda je provedena asynchronnˇe s hlavn´ım vl´aknem. Druh´a ˇc´ast programov´eho k´odu se nach´az´ı v metodˇe onPostExecute, kter´a m˚ uˇze komunikovat s uˇzivatelsk´ ym rozhran´ım spravovan´ ym hlavn´ım vl´aknem.
64
Vytvoˇren´e uk´azkov´e generovan´e aplikace“ ”
Zabezpeˇcen´e hlasovac´ı zaˇr´ızen´ı
Zde doch´az´ı ke zm´ınˇen´emu probl´emu. Volan´a DEX knihovna totiˇz po zaˇsifrov´an´ı dat vytvoˇr´ı objekt a pˇred´a mu informace pro s´ıt’ov´ y pˇrenos. Pak pˇred´a v´ ysledky zpˇet do generovan´e aplikace a skonˇc´ı. V dobˇe, kdy jiˇz zm´ınˇen´ y pˇrenos je ukonˇcen a je pˇred´ana n´avratov´a hodnota, generovan´a aplikace m´a jiˇz odpovˇed’ od DEX knihovny a zpracov´av´a dalˇs´ı u ´kony. K ˇreˇsen´ı tˇechto probl´em˚ u je v aktivitˇe pro generovan´e aplikace vytvoˇrena metoda makeText(String text), kter´a m´a za u ´kol zobrazit v hlavn´ım vl´aknˇe aktivity vykreslit informaˇcn´ı okno na obrazovce aplikace. Uk´azka, jak vypad´a generovan´a aplikace je vidˇet na obr´azku 9.3.
Obr´azek 9.3: Uk´azka generovan´e aktivity Zabezpeˇcen´e hlasovac´ı zaˇr´ızen´ı“ spuˇstˇen´e ” v emul´atoru.
65
10 Testov´an´ı aplikace Aplikace byla zkouˇsena na jiˇz zm´ınˇen´em emul´atoru v´ yvojov´eho prostˇred´ı Eclipse. Polymorfn´ı aplikace byla testov´ana na re´aln´em zaˇr´ızen´ı HTC One V se syst´emem Android verze 4.0.3. Pro emul´ator byla polymorfn´ı aplikace testov´ana ve verz´ıch Android 4.0 (API 14), 4.0.3 (API 15), 4.1 (API 16) a 4.2 (API 17). Na vˇsech tˇechto verz´ıch bylo chov´an´ı polymorfn´ı aplikace stejn´e a shodn´e s popisy uveden´ ymi v t´eto diplomov´e pr´aci. Na testovan´em zaˇr´ızen´ı fungovala polymorfn´ı aplikace stejnˇe jako na emul´atoru. T´ım se potvrdila jej´ı funkˇcnost i na nejniˇzˇs´ı“ verzi syst´emu Android, kter´a byla ” pro tuto pr´aci zvolena.
66
11 Moˇznosti budouc´ıho rozˇs´ıˇren´ı Vytvoˇrenou polymorfn´ı aplikaci lze d´ale rozˇsiˇrovat o funkˇcnosti a o generovan´e aplikace. Pro rozˇs´ıˇren´ı moˇzn´ ych druh˚ u generovan´ ych aplikac´ı je moˇzno do aplikace dodat dalˇs´ı prvky grafick´eho uˇzivatelsk´eho rozhran´ı (napˇr´ıklad obr´azkov´e pole, posuvn´ıky ˇci jin´e ovl´adac´ı prvky). Polymorfn´ı aplikace je pˇripravena na rozˇs´ıˇren´ı pro pˇrid´av´an´ı v´ıce aktivit do jedn´e generovan´e aplikace. K tomu lze vyuˇz´ıt adresy dalˇs´ıch XML popis˚ u generovan´ ych aplikac´ı, kter´e lze ukl´adat pod promˇenou URL2 pˇripravenou ve sd´ılen´ ych preferenc´ıch. Dalˇs´ım moˇzn´ ym rozˇs´ıˇren´ım aplikace by bylo pˇrid´an´ı v´ıce r˚ uzn´ ych druh˚ u ˇsifrov´an´ı vˇcetnˇe moˇznosti pr´ace s digit´alnˇe podepsan´ ymi soubory.
67
12 Z´avˇer ´ Ukolem diplomov´e pr´ace bylo navrhnout a realizovat princip polymorfn´ı aplikace pro mobiln´ı operaˇcn´ı syst´em Android. V r´amci n´avrhu byly probr´any r˚ uzn´e moˇznosti, jak by ˇslo tuto polymorfn´ı aplikaci vytvoˇrit. Jako nejvhodnˇejˇs´ı pro realizaci polymorfn´ı aplikace byly zvoleny dva druhy ˇreˇsen´ı. Prvn´ı je zpracov´an´ı k´odu prostˇrednictv´ım DEX knihovny z´ıskan´e ze vzd´alen´eho u ´loˇziˇstˇe. Druhou realizovanou moˇznost´ı je vyuˇz´ıv´an´ı vzd´alen´ ych procedur. Obˇe tyto varianty slouˇz´ı k tomu, aby aplikace pokryla svou funkˇcnost´ı co nejv´ıce moˇzn´ ych zp˚ usob˚ u chov´an´ı. K tomu, aby bylo moˇzn´e definovat chov´an´ı a grafick´e uˇzivatelsk´e rozhran´ı polymorfn´ı aplikace, byl navrˇzen pˇredpis ve form´atu XML. Princip pouˇzit´ı tohoto pˇredpisu je takov´ y, ˇze po pˇred´an´ı zm´ınˇen´eho pˇredpisu dojde k dynamick´emu vytvoˇren´ı generovan´e aplikace. Pomoc´ı navrˇzen´eho XML pˇredpisu lze pro grafick´e uˇzivatelsk´e rozhran´ı urˇcit, jak´e objekty a na jak´ ych m´ıstech se maj´ı vyskytovat. Objekty, kter´e lze pouˇz´ıt pro grafick´e uˇzivatelsk´e rozhran´ı generovan´e aplikace, jsou informaˇcn´ı popisek, editovateln´e textov´e pole, tlaˇc´ıtko a graf. Zm´ınˇen´ ymi objekty lze navrhnout prakticky jakoukoli formul´aˇrovou aplikaci. V´ yhoda spoˇc´ıv´a v tom, ˇze po u ´pravˇe XML pˇredpisu m˚ uˇze generovan´a aplikace plnit u ´plnˇe jin´ y u ´kol (respektive m´ıt odliˇsnou funkˇcnost). ˇ ast pr´ace byla tak´e vˇenov´ana zabezpeˇcen´ı navrhnut´e polymorfn´ı aplikace. NejC´ dˇr´ıve byly probr´any druhy poruˇsen´ı bezpeˇcnosti a bezpeˇcnostn´ıch rizik. Rizika bylo potˇreba nˇejak´ ym zp˚ usobem eliminovat tak, aby bylo moˇzn´e i dalˇs´ı pouˇz´ıv´an´ı polymorfn´ı aplikace. Jedn´ım z realizovan´ ych ˇreˇsen´ı bylo zabezpeˇcen´ı zaloˇzen´e na z´akladˇe ˇsifrov´an´ı dat a XML popis˚ u generovan´ ych aplikac´ı. Druh´a varianta zabezpeˇcen´ı spoˇc´ıv´a v omezen´ı pr´av pro polymorfn´ı aplikaci uveden´ ych v manifestu aplikace. Obˇe zm´ınˇen´a ˇreˇsen´ı zabezpeˇcen´ı pokr´ yvaj´ı novˇe vznikl´e bezpeˇcnostn´ı probl´emy. Pro ovˇeˇren´ı praktick´e pouˇzitelnosti a velk´eho rozsahu r˚ uzn´ ych funkˇcnost´ı byla vytvoˇrena sada generovan´ ych aplikac´ı. Sada generovan´ ych aplikac´ı obsahuje grafickou kalkulaˇcku, d´alkov´e ovl´ad´an´ı pro aplikaci VLC media player a zabezpeˇcen´e hlasovac´ı zaˇr´ızen´ı. Vytvoˇren´e aplikace maj´ı odliˇsn´e funkcionality a vyuˇz´ıvaj´ı jak zm´ınˇen´ ych knihoven z´ıskan´ ych ze vzd´alen´ ych u ´loˇziˇst’, tak i vzd´alen´ ych procedur poskytovan´ ych servery. Generovan´e aplikace jsou pro polymorfn´ı aplikaci pops´any XML soubory. Ty jsou vidˇet v pˇr´ıloze A t´eto pr´ace. Pro budouc´ı v´ yvoj´aˇre slouˇz´ı jako uk´azka a vzor moˇzn´eho principu, jak lze tyto generovan´e aplikace vyv´ıjet.
68
Literatura [Anu13] Using Hardware Devices. Android Developers [online]. 2013 [cit. 2013-0416]. Dostupn´e z: http://developer.android.com/tools/device.html. [Anw11] V´ıcevl´aknov´e zpracov´an´ı. AndroidWiki [online]. 6. 5. 2011, 22. 9. 2011 [cit. 2013-04-09]. Dostupn´e z: http://androidwiki.cz/V´ıcevl´aknov´e zpracov´an´ı. [Apa10] THE APACHE SOFTWARE FOUNDATION. Ws-xmlrpc: Apache XMLRPC [online]. 2001-2010 [cit. 2013-03-30]. Dostupn´e z: http://ws.apache.org/xmlrpc/. [Apa13] Apache Commons Net: Overview [online]. 2001-2013 [cit. 2013-04-09]. Dostupn´e z: http://commons.apache.org/proper/commons-net/. [Apc10] The Apache XML-RPC Client. THE APACHE SOFTWARE FOUNDATION. Ws-xmlrpc: Apache XML-RPC [online]. 2001-2010, 16.2.2010 [cit. 2013-03-30]. Dostupn´e z: http://ws.apache.org/xmlrpc/client.html. [Apl12] Androidplot.com: An Android API for creating charts and plots. [online]. 2012 [cit. 2013-03-13]. Dostupn´e z: http://androidplot.com/. [App13] Titanium Mobile Application Development. Appcelerator Inc. [online]. 2008-2013 [cit. 2013-04-29]. Dostupn´e z: http://www.appcelerator.com/platform/titanium-platform/. [Aps10] The Apache XML-RPC Server. THE APACHE SOFTWARE FOUNDATION. Ws-xmlrpc: Apache XML-RPC [online]. 2001-2010, 16.2.2010 [cit. 2013-03-30]. Dostupn´e z: http://ws.apache.org/xmlrpc/server.html. 69
[Goo09] Android-json-rpc: A json-rpc client library for android. Google Code [online]. 2009 [cit. 2013-03-12]. Dostupn´e z: https://code.google.com/p/android-json-rpc/. [Goo10] Ksoap2-android: A lightweight and efficient SOAP library for the Android platform. Google Code [online]. 2010 [cit. 2013-04-02]. Dostupn´e z: https://code.google.com/p/ksoap2-android/. [Hul12] HULA, Josef. Dynamick´a tvorba aplikac´ı v syst´emu Android [online]. ´ ˇ ´ UNIVERZITA 2012 [cit. 2013-02-26]. Bakal´aˇrsk´a pr´ace. ZAPADO CESK A V PLZNI, Fakulta aplikovan´ ych vˇed. Vedouc´ı pr´ace Ladislav Peˇsiˇcka. Dostupn´e z: http://theses.cz/id/vf9jn8/. [Chu11] CHUNG, Fred. Custom Class Loading in Dalvik. In: Android Developers Blog [online]. 28 July 2011 [cit. 2013-04-07]. Dostupn´e z: http://android-developers.blogspot.cz/2011/07/custom-classloading-in-dalvik.html. [Ibm13] JAR files revealed: Explore the power of the JAR file format. IBM: developerWorks [online]. [cit. 2013-03-10]. Dostupn´e z: http://www.ibm.com/developerworks/library/j-jar/. [Int99] THE INTERNET SOCIETY. RFC 2616 - Hypertext Transfer Protocol: HTTP/1.1 [online]. 1999, s. 176 [cit. 2013-04-02]. Dostupn´e z: http://tools.ietf.org/html/rfc2616. [Jav12] RPC: Remote Procedure Call protocol. Javvin: Network Protocols Guide, Network Monitoring & Analysis Tools [online]. 2012 [cit. 2013-03-10]. Dostupn´e z: http://www.javvin.com/protocolRPC.html. [Jin13] J-Interop: Pure Java-DCOM Bridge [online]. [cit. 2013-04-02]. Dostupn´e z: http://j-interop.org. ´ [Jso13] Uvod do JSON. JSON [online]. [cit. 2013-03-11]. Dostupn´e z: http://www.json.org/json-cz.html. [Kos01] KOSEK, Jiˇr´ı. Parsery: XML & aplikace. XML pro kaˇzd´eho [online]. 20002001 [cit. 2013-03-30]. Dostupn´e z: http://www.kosek.cz/clanky/swn-xml/ar02s30.html. [Lin11] LINTVELT, Herman. One CODE to rule them all. In: RichClientGUI [online]. 8 Jun 2011 [cit. 2013-04-06]. Dostupn´e z: http://blog.richclientgui.com/?p=449.
71
LITERATURA
LITERATURA
[Lyc11] Java RMI Overview. TAING, Nguonly. LYCOG [online]. 8.3.2011 [cit. 201303-13]. Dostupn´e z: http://lycog.com/distributed-systems/java-rmi-overview/. ´ Martin. REST: architektura pro webov´e API. Zdroj´ak: o tvorbˇe [Mal09] MALY, webov´ych str´anek a aplikac´ı [online]. 3.8.2009 [cit. 2013-04-02]. Dostupn´e z: http://www.zdrojak.cz/clanky/rest-architektura-pro-weboveapi/. [Mic11] MICHL, Petr. Je lepˇs´ı nativn´ı aplikace nebo mobiln´ı web?. Marketing journal: marketing, public relations, reklama, internet [online]. 25. 6. 2012 [cit. 2013-04-06]. Dostupn´e z: http://www.m-journal.cz/cs/internet/Je-lepsi-nativniaplikace-nebo-mobilni-web s281x9241.html. [Mot13] RhoMobile Suite. MOTOROLA SOLUTIONS, Inc. Motorola Solutions Homepage: Motorola Solutions USA [online]. 2013 [cit. 2013-04-29]. Dostupn´e z: http://www.motorola.com/Business/US-EN/Business +Product+and+Services/Software+and+Applications/RhoMobile +Suite. [Msd07] Distributed Component Object Model (DCOM) Remote Protocol Specification. MSDN: the Microsoft Developer Network [online]. 2007 [cit. 201304-02]. Dostupn´e z: http://msdn.microsoft.com/library/cc201989.aspx. ˇ [Mun07] Sifrov´ an´ı. In: FAKULTA INFORMATIKY MASARYKOVY UNIVERZITY. FI WIKI [online]. 2007, 25. 5. 2007 [cit. 2013-04-13]. ˇ Dostupn´e z: http://kore.fi.muni.cz/wiki/index.php/Sifrov´ an´ı. [Mur11] MURPHY, Mark L. Android 2: pr˚ uvodce programov´an´ım mobiln´ıch aplikac´ı. Vyd. 1. Brno: Computer Press, 2011, 375 s. ISBN 978-80-251-3194-7. [Ocs10] DistributedObjects. OCSOFTWARE. OCSite [online]. 2010 [cit. 2013-0429]. Dostupn´e z: http://www.ocs.cz/text/NeXTStep/DistributedObjects.html. [Pho13] PhoneGap [online]. 2013 [cit. 2013-04-29]. Dostupn´e z: http://phonegap.com/. [Rho09] RHODES, Loren K. ODMG and CORBA. Juniata College [online]. 2009, 20.10.2009 [cit. 2013-04-02]. Dostupn´e z: http://jcsites.juniata.edu/faculty/rhodes/dbms/odmg.htm.
72
LITERATURA
LITERATURA
[Sci11] XML-RPC.Com: Simple cross-platform distributed computing, based on the standards of the Internet. [online]. Scripting News, Inc., 2004-2011 [cit. 201303-30]. Dostupn´e z: http://xmlrpc.scripting.com/. [Scr11] Dalvik, virtual machine of Android. Scriptol.com: Programming with web standards [online]. 2011 [cit. 2013-03-10]. Dostupn´e z: http://www.scriptol.com/programming/dalvik.php. [Sdk13] Android SDK. Android Developers [online]. 2013 [cit. 2013-03-12]. Dostupn´e z: http://developer.android.com/sdk/index.html. ˇ ˇ [Sch13] SCHREINER, Pavel a Petr HRUSKA. CVUT. Java RMI [online]. [cit. 201305-01]. Dostupn´e z: http://kmdec.fjfi.cvut.cz/ virius/prednes/prezen/rmi.pdf. ˇ [Sra08] SRAJER, Michal. INMITE S.R.O. Android session: 1. poloˇcas [online]. 2008, 32 s. [cit. 2013-03-10]. Dostupn´e z: http://android.inmite.eu/data/android slajdy 01.pdf. [Tom13] Tomcat Web Application Deployment. THE APACHE SOFTWARE FOUNDATION. Apache Tomcat 7.0 [online]. 1999-2013, Mar 22 2013 [cit. 2013-04-16]. Dostupn´e z: http://tomcat.apache.org/tomcat-7.0-doc/deployerhowto.html. [Vid10] Controlling VLC via rc from java. In: The VideoLAN Forums [online]. 15 December 2010 [cit. 2013-04-09]. Dostupn´e z: http://forum.videolan.org/viewtopic.php?f=14&t=85347. [Vir10] VIRTUAL MOBILE TECHNOLOGIES. RAMP Secure Mobile Enterprise Application Platform (MEAP) [online]. 2010 [cit. 2013-04-29]. Dostupn´e z: http://ramp.virtualmobiletech.com/. [Vlc12] VideoLAN: Official page for VLC media player, the Open Source video framework! [online]. 1996-2012 [cit. 2013-04-09]. Dostupn´e z: http://www.videolan.org/vlc/. [W3j99] JSON Tutorial. W3schools [online]. 1999-2013 [cit. 2013-04-02]. Dostupn´e z: http://www.w3schools.com/json/. [W3s99] SOAP Tutorial. W3schools [online]. 1999-2013 [cit. 2013-04-02]. Dostupn´e z: http://www.w3schools.com/soap/.
73
A Uk´azky vytvoˇren´ych XML A.1
Grafick´ a kalkulaˇ cka - RPC
V pˇr´ıloze je vidˇet XML popis, kter´ y je vytvoˇren k aplikaci Grafick´a kalkulaˇcka“ ” ve verzi RPC. Generovan´a aplikace byla podrobnˇe pops´ana v kapitole 9.1. Popis XML obsahuje celkem osm prvk˚ u. Prvn´ıch ˇsest prvk˚ u popisu je uspoˇra´d´ano ve dvojic´ıch. Tyto dvojice jsou sloˇzeny z textov´eho popisku (neboli textview) a editovateln´eho textov´eho pole (edittext). Sedm´ ym prvkem XML popisu je ovl´adac´ı prvek (button), jehoˇz u ´kolem je definovat, jak´ ym zp˚ usobem bude prov´adˇeno zpracov´an´ı aplikace. V uveden´em pˇr´ıpadˇe jde o zpracov´an´ı pomoc´ı RPC na serveru. Posledn´ım prvkem je objekt typu graf, ve kter´em se zobrazuj´ı v´ ysledn´e pr˚ ubˇehy z´ıskan´e z proveden´e RPC procedury na serveru.
76
Uk´azky vytvoˇren´ych XML
A.2
Grafick´a kalkulaˇcka - DEX
Grafick´ a kalkulaˇ cka - DEX
V pˇr´ıloze je vidˇet XML popis, kter´ y je vytvoˇren k aplikaci Grafick´a kalkulaˇcka“ ” ve verzi DEX. Popis obsahuje celkem osm prvk˚ u. Popis varianty je podobn´ y jako v pˇredchoz´ı pˇr´ıloze A.1. Jedin´ ym rozd´ılem je definice ovl´adac´ıho prvku. Ten m´a v XML popisu nastaven zp˚ usob zpracov´an´ı DEX. To definuje, ˇze je potˇreba z´ıskat urˇcenou DEX knihovnu. Ta je v n´asleduj´ıc´ım popisu definov´ana adresou DEX knihovny, typem a jm´enem funkce, kter´a m´a b´ yt ve zm´ınˇen´e DEX knihovnˇe zpracov´ana.
79
Uk´azky vytvoˇren´ych XML
A.3
D´alkov´y multimedi´aln´ı ovladaˇc
D´ alkov´ y multimedi´ aln´ı ovladaˇ c
Pˇr´ıloha ukazuje XML popis, kter´ y je vytvoˇren k aplikaci D´alkov´ y multimedi´aln´ı ” ovladaˇc“ popsan´e v kapitole 9.2. Popis aplikace obsahuje dvan´act prvk˚ u. Prvn´ı dva prvky obsahuj´ı informaˇcn´ı popisky. Dalˇs´ıch ˇsest prvk˚ u obsahuje tlaˇc´ıtka pro jednotliv´e akce, kter´e byly vybr´any jako nejpouˇz´ıvanˇejˇs´ı. N´asleduj´ıc´ı prvek obsahuje popisek pouze s jednou mezerou pro optick´e oddˇelen´ı prvk˚ u grafick´eho rozhran´ı. Posledn´ı tˇri prvky patˇr´ı do sekce pro pr´aci s pˇrehr´avaˇcem pˇres pˇr´ıkazovou ˇra´dku. Prvn´ım je popisek, druh´ y je editovateln´e textov´e pole a posledn´ım je prvek s funkˇcnost´ı RPC.
83
Uk´azky vytvoˇren´ych XML
A.4
Zabezpeˇcen´e hlasovac´ı zaˇr´ızen´ı
Zabezpeˇ cen´ e hlasovac´ı zaˇ r´ızen´ı
V pˇr´ıloze je vidˇet uk´azka XML popisu generovan´e aplikace nazvan´e Zabezpeˇcen´e ” hlasovac´ı zaˇr´ızen´ı“ popsan´e v kapitole 9.3. Aplikace se skl´ad´a ze tˇr´ı prvk˚ u. • Prvn´ım prvkem je popisek aplikace. • Druh´ ym prvkem je editovateln´e textov´e pole. To slouˇz´ı pro zad´an´ı n´azoru uˇzivatele. • Posledn´ı prvek je ovl´adac´ı tlaˇc´ıtko s DEX funkˇcnost´ı.
85
B Uk´azka k´odu pro DexClassLoader Tato pˇr´ıloha ukazuje zdrojov´ y k´od pro DexClassLoader popsan´ y v textu pr´ace.
final File optimizedDexOutputPath = getDir("outdex", Context.MODE_PRIVATE); DexClassLoader cl = new DexClassLoader(dexInternalStoragePath .getAbsolutePath(), optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader()); Class libProviderClazz = null; try { libProviderClazz = cl.loadClass("com.android.dpapp1." + nameOfFileWithoutExt); LibraryInterface lib = (LibraryInterface) libProviderClazz.newInstance(); ArrayList<String> parameters = new ArrayList<String>(); ArrayList<String> outParameters = new ArrayList<String>(); /** * Prochazeni vsech objektu a u tech, * ktere jsou edittextem zjisteni * jejich atributu popisek */ for (int i = 0; i < objectsList.getNameOfObject().size(); i++) { if (objectsList .getType().get(i).trim() .toLowerCase().equals("edittext")) { 86
Uk´azka k´odu pro DexClassLoader
int idOfCurrentObject = objectsList.getID().get(i); parameters.add (edittexts[idOfCurrentObject] .getText().toString()); } } /** vyuziti knihovni funkce stazene ze site */ outParameters = lib.doLibraryFunction(nameOfFunction, parameters); int returnCode = 0; try { returnCode = Integer.parseInt(outParameters.get(0)); } catch (Exception e) { returnCode = -1; ... return; }
87
C Zprovoznˇen´ı polymorfn´ı aplikace V pˇr´ıloze jsou pops´any zp˚ usoby spuˇstˇen´ı polymorfn´ı aplikace. Pro pˇr´ıklad lze pouˇz´ıt n´asleduj´ıc´ı dva zp˚ usoby: • Spuˇstˇen´ı pˇres emul´ator programu Eclipse. • Spuˇstˇen´ı v re´aln´em zaˇr´ızen´ı. Tyto zp˚ usoby jsou popsan´e d´ale.
C.1
Spuˇ stˇ en´ı pˇ res emul´ ator
Pro spuˇstˇen´ı polymorfn´ı aplikace na emul´atoru lze vyuˇz´ıt pˇripraven´eho v´ yvojov´eho prostˇred´ı [Sdk13]. Zde lze tak´e naj´ıt n´avody na zprovoznˇen´ı prostˇred´ı a jeho konfiguraci. D´ale je v tomto zdroji moˇzno naj´ıt n´avody na staˇzen´ı bal´ık˚ u potˇrebn´ ych pro emul´ator a spr´avn´ y bˇeh aplikace. Po nainstalov´an´ı a spuˇstˇen´ı v´ yvojov´eho prostˇred´ı je potˇreba naimportovat projekt polymorfn´ı aplikace. To provedeme zvolen´ım n´asleduj´ıc´ı poloˇzky File → Import → Existing Android Code Into Workspace. Potvrd´ıme tlaˇc´ıtkem Next. V dalˇs´ım oknˇe vybereme Root Directory a vloˇz´ıme adresu existuj´ıc´ıho projektu polymorfn´ı aplikace. Pˇred pokraˇcov´an´ım zaˇskrtneme poloˇzku Copy projects into workspace. Tlaˇc´ıtkem Finish dokonˇc´ıme import projektu. N´asleduj´ıc´ım krokem je vytvoˇren´ı virtu´aln´ıho zaˇr´ızen´ı pro Android. Pro vytvoˇren´ı virtu´aln´ıho zaˇr´ızen´ı je potˇreba ve sloˇzce, kde je um´ıstˇen Android, na dan´em poˇc´ıtaˇci spustit tzv. Android Virtual Device Manager“ (soubor AVD Manager.exe). V nˇem ” lze vytvoˇrit pomoc´ı tlaˇc´ıtka New... nov´e virtu´aln´ı zaˇr´ızen´ı dle vlastn´ıch potˇreb. Po vytvoˇren´ı potˇrebn´eho virtu´aln´ıho zaˇr´ızen´ı staˇc´ı zaˇr´ızen´ı zvolit v nab´ıdce a stisknout tlaˇc´ıtko Start. T´ım dojde ke spuˇstˇen´ı emul´atoru s mobiln´ım syst´emem Android. Ten bude spuˇstˇen s preferencemi, kter´e byly nastaveny bˇehem jeho vytv´aˇren´ı. Pro samotn´e spuˇstˇen´ı pak v Eclipse klepneme prav´ ym tlaˇc´ıtkem na adres´aˇr projektu polymorfn´ı aplikace, kter´ y jsme na zaˇc´atku tohoto n´avodu importovali. Zvol´ıme poloˇzku Run As → Android Appliaction. T´ım dojde ke spuˇstˇen´ı polymorfn´ı aplikace v bˇeˇz´ıc´ım emul´atoru. 88
Zprovoznˇen´ı polymorfn´ı aplikace
C.2
Spuˇstˇen´ı na re´aln´em zaˇr´ızen´ı
Spuˇ stˇ en´ı na re´ aln´ em zaˇ r´ızen´ı
Spuˇstˇen´ı na re´aln´em zaˇr´ızen´ı, na kter´em je nasazen mobiln´ı syst´em Android lze dvˇema zp˚ usoby. • Prvn´ı moˇznost´ı je vyuˇzit´ı Eclipse pro spuˇstˇen´ı polymorfn´ı aplikace na mobiln´ım zaˇr´ızen´ı - viz n´avod [Anu13]. • Druhou moˇznost´ı je nahr´an´ı souboru .apk ze sloˇzky projektu do zaˇr´ızen´ı a nainstalovat polymorfn´ı aplikaci pˇr´ımo v zaˇr´ızen´ı.
89
D Zprovoznˇen´ı serveru Nˇekter´e aplikace pro svou ˇcinnost vyuˇz´ıvaj´ı vytvoˇren´ ych RPC server˚ u, kter´e je potˇreba pˇred spuˇstˇen´ım polymorfn´ı aplikace nasadit a spustit. Nasazen´ı a spuˇstˇen´ı server˚ u Tomcat, kter´e byly pˇri v´ yvoji pouˇz´ıv´any je pops´ano v [Tom13]. Druh´ ym zp˚ usobem je spuˇstˇen´ı serveru z Eclipse IDE for Java EE Developers s nainstalovanou Java 7. Eclipse je potˇreba nakonfigurovat: Nejdˇr´ıve zvol´ıme Window → Preferences → Server → Runtime Enviroments → Add. N´aslednˇe pak vybereme Apache → Apache Tomcat v7.0 a potvrd´ıme tlaˇc´ıtkem Next. V dalˇs´ım oknˇe je tˇreba doplnit cestu k adres´aˇri Tomcat install dir, kde se Tomcat nach´az´ı. Potvrd´ıme tlaˇc´ıtkem Finish. Dalˇs´ım krokem je pˇrid´an´ı serveru v Eclipse pomoc´ı File → New → Other → Server a po stisknut´ı tlaˇc´ıtka Next vyplnit n´asleduj´ıc´ı: • host name = localhost • type = Tomcat v7.0 Server • runtime = viz instalaˇcn´ı cesta k adres´aˇri, kde se Tomcat nach´az´ı. Nastaven´ı potvrd´ıme tlaˇc´ıtkem Finish. Posledn´ım krokem pˇred spuˇstˇen´ım je pˇriˇrazen´ı Tomcat serveru projektu. Do Eclipse pak staˇc´ı naimportovat projekt obsahuj´ıc´ı serverovou ˇca´st pr´ace a klepnut´ım prav´ ym tlaˇc´ıtkem myˇsi na Tomcat v7.0 Server at localhost pˇres nab´ıdku Add and Remove... pˇriˇradit Tomcat server projektu. Spuˇstˇen´ı serveru se pak provede klepnut´ım prav´ ym tlaˇc´ıtkem na projekt a zvolen´ım poloˇzky Run As → Run on Server. Po spuˇstˇen´ı se zobraz´ı okno intern´ıho prohl´ıˇzeˇce Eclipse s adresou bˇeˇz´ıc´ıho serveru. To by mohlo vypadat napˇr´ıklad takto: http://localhost:8080/xml-rpc-server/ Na konec adresy pak staˇc´ı pˇridat /xmlrpc a str´anku znovu naˇc´ıst (napˇr´ıklad pomoc´ı tlaˇc´ıtka refresh). Pokud bude str´anka hl´asit chybu ˇc´ıslo 405, tak server s RPC je pˇripraven pˇrij´ımat poˇzadavky od klienta. 90
