Vývoj mobilních aplikací - PDF\nDownload "Vývoj mobilních aplikací"\n1 Bankovní institut vysoká škola Praha Katedra informatiky a kvalitativních metod Vývoj mobilních aplikací Diplomová práce Autor: Bc. Tomáš Hochmuth Informační technologie a management Vedoucí práce: Ing. Jan Háněl Praha Duben, 2014\n2 Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Třebíči dne Bc. Tomáš Hochmuth\n3 Poděkování V této části práce bych chtěl nejprve poděkovat svému vedoucímu panu Ing. Hánělovi, který velmi trpělivě vedl mojí práci. Mé největší díky však patří mé mamince, která mi vytvořila báječné podmínky pro studium a tvorbu této práce.\n4 ANOTACE Diplomová práce na téma vývoj mobilních aplikací pojednává o rozsáhlé problematice, která sestává z návrhu a optimalizace aplikací určené pro chytré mobilní telefony a tablety. Cílem práce je návrh mobilní aplikace z oboru bankovnictví, která by byla kompatibilní s operačním systémem Google Android. Práce pojednává o všech úskalích a nástrahách vývoje pro mobilní zařízení a díky praktickému výstupu tak může plnit roli příručky pro začínající vývojáře. Bohatý teoretický základ čtenáře provede veškerými odlišnostmi vývoje pro různé operační systémy a poskytne také kvalitní souhrn informací, které by mohl takový vývojář při svých začátcích potřebovat. KLÍČOVÁ SLOVA Vývoj aplikací, Android, Bankovní kalkulátor, chytré telefony, tablety SUMMARY The diploma thesis deals with the development of mobile applications on large-scale problems, which consists of the design and optimization applications designed for smart phones and tablets. The aim of the work is to design a mobile application in the field of banking that would be compatible with the operating system Google Android. The work covers all the pitfalls and dangers of development for mobile devices and through practical output can act as guides for novice developers. Rich theoretical basis will guide the reader through all the differences in development for various operating systems and also provide a summary of the quality of information which also a beginner developer could find usefull. KEYWORDS Application Development, Android, Bank calculator, smart phones, tablets\n5 Obsah Úvod do teoretické části práce... 1 Cíl práce... 2 Historie mobilních platforem... 3 Google Android... 4 Apple ios... 6 Windows Phone... 8 Úvod do vývoje mobilních aplikací Architektura OS Android Členění vrstev architektury OS Android Rozdělení aplikací dle multiplatformního řešení Nativní aplikace Webové aplikace Hybridní aplikace Anatomie aplikací pro OS Android Notifikace (oznámení) Toast oznámení Oznámení ve stavovém řádku Oznámení formou dialogového okna Životní cyklus aplikace Životní cyklus aktivity Vlákna a procesy Priorita procesů Vlákna Android Manifest Elementy Atributy Přístupová oprávnění Knihovny Úrovně API (API Level) Nástroje pro vývoj v operačním systému Android Eclipse Android SDK HyperNext Android Creator... 27\n6 IntelliJ IDEA PhoneGAP Oracle ADF Mobile Uživatelské rozhraní OS Android Rozvržení obrazovky Rotace obrazovky při změně polohy zařízení Vizuální komponenty systému Android Textové popisky Tlačítka Zaškrtávací tlačítka Přepínače Obrázky Úvod do praktické části práce Java Development Kit (JDK) Software Development Kit (SDK) Základní konfigurace SDK: Doporučená konfigurace SDK: Plné konfigurace SDK: Optimalizace vývojového prostředí Eclipse Tvorba aplikací úvod do softwarového inženýrství Problémy při vývoji softwaru Etapy životního cyklu softwaru Analýza a návrh projektu Bankovní kalkulátor Definice vizuálního stylu aplikace Základní layout aplikace Implementace Algoritmus Základní komponenty aplikace Struktura projektu Bankovní kalkulátor Obsah kořenového adresáře Testování Emulátor Uživatelské testování Závěr... 62\n7 Seznam použité literatury Tištěné monografie Elektronické monografie... 63\n8 Úvod do teoretické části práce Vývoj mobilních aplikací prošel v několika posledních letech velmi dramatickými změnami. Prakticky stejnými, jako mobilní platformy samotné. Poprvé v historii je vývoj aplikací pro mobilní zařízení založených na ARM architektuře mohutnější a také výnosnější, než vývoj pro klasické desktopové platformy Windows či Unix. Prodeje herních titulů pro operační systémy mobilních telefonů v poslední době neustále rostou a již v této době můžeme mluvit o výrazném navýšení množství her, prodaných pro nejrozšířenější mobilní OS Android a ios. Dle průzkumů jsou lidé ochotnější zaplatit za mobilní aplikaci spíše, než za její variantu pro desktop. Jedná se o jakýsi bludný kruh, jelikož nelegální trh s aplikacemi roste a útoky na citlivá data uživatelů se násobí. Kvalitní antivirový program by neměl chybět v žádném desktopu vybaveném produkty Microsoftu. Toto tvrzení již stále více aplikujeme i u mobilních telefonů. Zejména nejmladší a nejrozšířenější systém od Google Android, se útoky malwaru doslova hemží. Užívání chytrého mobilního telefonu tak přestává být jednoduché a tato situace výrazně dopomáhá mnoha nově startujícím firmám ke vzniku nových služeb, kterými jsou například uvedení chytrého mobilního telefonu do provozu, základní nastavení, vybavení nejlepšími a nejbezpečnějšími aplikacemi pro denní využití, apod. Byznys kolem chytrých telefonů roste a představitelé nadnárodních korporací se zaměřením na IT, chrlí prognózy o brzkém útlaku klasických stolních počítačů i notebooků. Jejich náhradou mají být právě smartphony či tablety, tzv. přístroje do postele pro kvalitní konzumaci elektronického obsahu. Dobrý operační systém je dnes souhrn perfektní funkčnosti, hardwarové nenáročnosti a u mobilních platforem také dostatkem aplikací, které dělají systém uživatelsky atraktivním a přívětivým. V tuto chvíli jsou na trhu pouze dva opravdu silní hráči. Apple, který společně s jedním neustále inovovaným produktem iphone (případně ipad v roli tabletu) vytvořil dokonalý ekosystém aplikací AppStore a hudby itunes. Pokud přičteme také zálohování prostřednictvím Time Machine, či sledování televize přes Apple TV, je tento jablečný výrobce dokonalým představitelem inovátora na poli chytrých mobilních přístrojů a služeb. Druhým, v některých zemích již stále více dominantním konkurentem, je OS Android od společnosti Google. V prvních verzích nebyl zrovna čestným souputníkem, ovšem v posledních aktualizacích zejména na verzi Kit Kat se dá již hovořit o perfektním konkurentovi ios od Apple. Největší vývojářskou předností Androidu je jeho otevřený kód, který může upravit téměř každý. Z uživatelského hlediska pak oceníme propracovaný Android Market, který nově nalezneme pod jménem Obchod Play (anglicky Play Store ). V něm uživatel nalezne statisíce aplikací a her pro nepřeberné množství 1\n9 modelů mobilních telefonů. A právě tomuto mladému operačnímu systému se bude tato diplomová práce věnovat. Cíl práce Vývoj aplikací z hlediska různorodých platforem operačních systémů je vždy zdlouhavá systematická činnost, kterou není vhodné uspěchat. Na zahraničních trzích byl v minulých letech dominantní Apple, ovšem s masovým rozšířením Androidu se karty obrátily. Android, jehož podobnost lze nalézt v Linuxu, prošel ohromnými změnami a vývoj aplikací pro tuto platformu nabývá na popularitě. Podniky se stále více ubírají cestou open-source řešení a podobně založený mobilní systém tento fakt jen podpořil. Firmy marně shánějí kvalitní programátory a některé vysoké školy již na tento chybějící článek v řetězci zareagovaly vypsáním specifických předmětů, ve kterých se vývoj pro Android přímo vyučuje. Nezbytností se však stává alespoň základní znalost objektově orientovaného jazyka Java. Spojením androidího frameworku Android SDK a vývojového softwaru Eclipse vzniklo intuitivní a stabilní prostředí pro vývoj všech typů aplikací, určených pro tento systém. Programovat lze samozřejmě v jakémkoliv vývojovém prostředí, ať už je to obyčejný poznámkový blok, či sofistikovaný vývojový software, který vývojáři usnadní spoustu práce. Osobně jsem si pro vývoj aplikace vybral již zmíněné Eclipse, jakožto open-source vývojové prostředí pro přímé programování v Javě. Cílem této diplomové práce je tedy letmé představení mobilního operačního systému Android se specifikami vývoje pro tento systém. Výstupem této práce bude aplikace na téma bankovního kalkulátoru, která doplní i mé teoretické znalosti v oblastech bankovnictví. Bankovní kalkulačka bude po zadání nezbytných atributů schopna vypočíst měsíční splátku včetně celkového úroku a celkové částky zaplacené bance. Studijní oporou při vývoji aplikace a tvorbě této práce mi byly tři tištěné a výborně napsané publikace, které jsou nyní téměř povinnou četbou každého, kdo chce pro Android vyvíjet. Jedná se o knihy Programujeme pro Android od Miroslava Ujbányaiho, Android 2 od Marka L. Murphyho a Android 4 od Granta Allena. Společně s dokonale zpracovanými tutoriály od Google, dostupnými na adrese developer.android.com se jedná o kvalitní vědomostní základnu. 2\n10 Historie mobilních platforem Není tomu tak dlouho, kdy mobilní aplikace pro běžné, dnes již tzv. hloupé telefony znamenaly využití technologie Java aplikace takto vytvořené měly datovou strukturu JAR a do mobilního telefonu se instalovaly většinou přes WAP ( Wireless Application Protocol ), či pomocí USB kabelu. Nebylo tedy těžké obstarat si základní programové vybavení. Bohužel stinnou stránkou byly často poměrně vysoké ceny těchto aplikací. Připojení na web bylo velmi drahé a kvalitních aplikací pomálu. S příchodem prvních smartphonů, tedy chytrých telefonů vybavených operačním systémem se situace začala postupně projasňovat. Nutno dodat, že není to operační systém, který automaticky dělá chytrý telefon chytrým. Předpokladů je mnoho a zajímavým příkladem může být i uzavřený ekosystém, vytvořený Samsungem, který navrhl operační systém pro hrstku vyvolených modelů pod shodným označením Wave. Součástí takového telefonu již byl procesor, operační paměť atp. Tedy vybavení shodné s osobním počítačem a zadávající předpoklad pro první generaci smartphonů. Tento systém zvaný jednoduše Samsung OS (později OS Bada) obsahoval i první online obchod pro nákup aplikací, těch však bylo velmi málo a s nastupujícím Androidem se zájem o něj stočil jiným směrem. Bada měla přitom našlápnuto na pozici, ve které by silně konkurovala tehdy nedokonalému Androidu či Symbianu. S příchodem modelů Galaxy však Samsung ukončil další vývoj a ohlásil budoucí návrat platformy, vylepšeným o spolupráci se společností Intel. Nový operační systém by měl nést název OS Tizen. Nesmírně důležitým článkem ve vývoji operačních systémů pro mobilní telefony byla Nokia. Počáteční vývoj mobilního OS probíhal ve spolupráci s Motorolou, Ericssonem a Psionem již v roce Pravý operační systém v té podobě, ve které ho většina z nás zná, přišel kolem roku Byl představen komunikátor Nokia 9210 s otevřenou platformou Symbian verze 6. Prodeje byly dech beroucí a mnoho lidí tento typ přístroje používá dodnes. O tři roky později můžeme hovořit o odladěném systému, který nalezneme na nepřeberném množství mobilních telefonů, pozdější verze se vždy vyznačovaly podporou některých v té době exotických technologií. V roce 2004 uměl Symbian mobilní síť třetí generace, bylo jej tedy možné (zejména v zahraničí) používat coby prohlížeč internetových stránek. Velice významnými a bohužel i takřka posledními verzemi byl Symbian Anna a Belle, které se vyznačovaly nízkými nároky na hardware telefonu a jejíchž uživatelské prostředí se čím dál více inspirovalo rostoucím Androidem. Ať byl Symbian jakkoliv průlomovým systémem, 1 Symbian OS. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, [cit ]. Dostupné z: 3\n11 hřebíčkem do rakve mu byly právě aplikace. Respektive jejich výrazný nedostatek. Jak již v úvodu zaznělo, jsou to právě tržiště s aplikacemi, která dělají mobilní operační systémy atraktivními. Nezájem ze strany vývojářů se podepsal na postupném konci této platformy. Nokia se rozhodla Symbian opustit a přejít k redmonskému Microsoftu. V současnosti již spolehlivě víme, že smluvní akt Nokie podmíněný distribucí svých modelů s operačním systémem Windows Phone byl svým způsobem upsání ďáblovi. Dnes již silné trio systémů ios od Apple, Android od Google a Windows Phone od Microsoftu nic a nikomu neodpouštějí. Na trhu toto trio obsadilo vůdčí pozice a slabší články v podobě minoritních systémů již neměly šance uspět. Google Android V roce 2008 přišel na trh velmi silný hráč, který zamíchal kartami, aby později převzal žezlo na poli mobilních telefonů. Systém, který vytvořila hrstka programátorů v čele s Andy Rubinem, coby jednoduchý koncept operačního systému konkurující zavedenému systému ios od Applu. Byl jím Android ve verzi 1.0 založený na linuxovém jádře Tentýž rok představila firma HTC svůj první a dnes již legendární Android telefon Dream (prodávaný také jako T-Mobile G1). Android se od této chvíle dramaticky měnil a první výrazná změna přišla s verzí 1.5 s kódovým označením Cupcake. Zde mluvíme již o plnohodnotném systému pro mobilní telefony všech značek. Došlo k implementaci virtuální klávesnice, přidáno bylo množství systémových animací a v neposlední řadě přibylo také mnoho uživatelských vylepšení, jako přímé nahrávání videí na portál YouTube či rotace aplikací při rotaci displeje. Netrvalo půl roku, kdy vyšla další verze s číslem 1.6 a kódovým označením Donut. Ta přinesla plnou podporu VPN a syntézu řeči. Jen o měsíc později následovala verze 2.0/2.1 Eclair, která mimo jiné vylepšila rychlost hardwaru, přinesla nové mapy, podporu HTML5 a také Bluetooth 2.1. V květnu 2010 přišla donedávna nejrozšířenější verze 2.2 Froyo, která umožnila přesouvat instalace aplikací na paměťovou kartu, což bylo velmi důležité pro smartphony z levné produkce, nedisponující větší interní pamětí. Tato verze nabídla plnohodnotný Adobe Flash, zlepšovala také využití operační paměti a zejména umožnila tzv. tethering. Tedy vytvoření bezdrátového Wi-Fi hotspotu. Zanedlouho dorazila určitou dobu velmi populární verze 2.3 Gingerbread, která se usídlila zejména ve slabších přístrojích. Tato verze přinesla plnou podporu technologie NFC a zlepšila se také správa paměti. Pro uživatele došlo ke zlepšení funkce copy/paste. Přímou odnoží od zavedeného Gingerbreadu byla specifická verze pro tablety. Zajímavostí byl fakt, že doposud byly všechny vývojové větve Androidu vždy open-source. Android ve verzi 3.0 a jeho inovované 4\n12 subverze 3.1 a 3.2 s kódovým označením Honeycomb byl naprogramován za účelem prodeje IT korporacím, které tuto verzi později upravovaly o svoje grafické nadstavby. Výhodou Honeycombu byla bezesporu výborná optimalizace pro velké obrazovky. Inovovaný vzhled přispěl k masovému rozšíření tabletů s Androidem. Ve srovnání s konkurencí, které nebylo mnoho a byl jím prakticky nejznámější tablet z rodiny Apple ipad, však Android stále ztrácel. HoneyComb neustál trendy na design a záhy jej vystřídala revoluční verze určená jak pro telefony tak i tablety. Koncem roku 2011 vzešla čtvrtá verze s označením Ice Cream Sandwich, která dokázala zaujmout inovacemi v podobě odemykání telefonu obličejem, panoramatickým focením či vylepšeným hlasovým ovládáním. Inovací bylo mnoho a v odborné veřejnosti se mluvilo o plnohodnotném konkurentovi iphone od Applu. Netrvalo však dlouho a spekulace o novém nástupci padly přesně , kdy byla představena nikoliv inovovaná verze čtvrté generace Androidu, ale zcela nový systém s unikátními prvky funkcionality, který až nyní můžeme považovat za výrazného konkurenta ios. Jedná se o verzi 4.1/4.2 Jelly Bean. Nejzásadnější inovací byl projekt Butter, který výrazným způsobem zrychlil běh celého systému. Fotoaparát dostal funkci sférického focení, tedy schopnost vytvářet prostorové snímky. Podpora uživatelských účtů, které známe z desktopů či Google Now je jen příjemným vylepšením jinak téměř perfektního operačního systému. V současné době mluvíme o nástupci, který díky kontraktu s firmou Nestlé dostal název Kit Kat. Verze 4.4, která se již dočkala i prvních aktualizací, byla představena 3. září roku 2013 a přináší kromě stávajících funkcí Jelly Beanu také novou verzi linuxového jádra, který lépe hospodaří s operační pamětí a který je také lépe optimalizován pro více jádrové procesory. Hlavní devizou této verze je výrazně zlepšená rychlost systému, která vynikne zejména na čistém Androidu z rodiny přístrojů Nexus. Obrázek 1: Grafický přehled verzí OS Android [převzato z Google.com] 5\n13 Apple ios Nezávisle na oblibě jablečných produktů se musí úvodem uznat Steve Jobs byl vizionář a svojí revolucí v podobě dosud nevídaného mobilního telefonu iphone, udělal mezi běžnými lidmi značný rozruch. Od roku 2004 pracoval na přísně tajném projektu Purple, aby o tři roky později představil světu telefon, za který by se nemusel stydět leckterý sci-fi film. Telefon, jehož ovládání bylo pouze dotykové a jehož displej byl nejjemnější, který jsme dosud v telefonu kdy viděli. Během jednoho dne se z iphone stal naprostý prodejní hit, který bořil zažité konvence. Fenomenální projev Steva Jobse dnes můžeme považovat za legendární a tak, jak úspěšně startoval iphone, tak i jeho zvětšená tabletová verze zvaná ipad, trhala neuvěřitelné prodejní rekordy. Ostatně, dnes již můžeme s klidným svědomím říci, že to byl právě Apple, který odstartoval vysokou poptávku po dotykových mobilních telefonech s operačním systémem. Dá se tedy nadneseně říci, že ostatní jen kopírovali. S postupnými nároky uživatelů rostly i verze iphonu. V roce 2008 přišla verze 3G, která přinesla podporu UMTS sítí a GPS navigace. O rok později mluvíme o inovované verzi 3GS, která získala rychlejší procesor, dvojnásobnou velikost paměti a funkci digitálního kompasu. Byla také zlepšená dotyková vrstva displeje, která více odolávala otiskům prstů. V roce 2010 představil Apple světu iphone 4, který dostal zejména inovovaný vzhled. Ten se mnohým lidem nezalíbil a tak od Applu nadobro odešli. Kdo přetrval, ocenil konstrukci kombinující hlinitokřemičité sklo s nerezovými okraji, které sloužily jako anténa. Po celém světě zanedlouho propukla aféra s vypadávajícím signálem při nesprávném úchopu telefonu. V USA se vžilo spojení Antenna-Gate. Apple tento nešvar řešil speciálním pouzdrem zvyšující signál přístroje. Za tento krok sklidil velkou nespokojenost a odliv zákazníků směrem ke stále rostoucímu Androidu. Tato čtvrtá generace iphonu přinesla velmi jemný displej s rozlišením 960 x 640 bodů s marketingovým označením RETINA. Toto spojení můžeme nalézt jak u notebooků řady Macbook, tak i u tabletů řady ipad. Pátá generace iphone, o které se hovořilo, jako o další revoluci přinesla spíše zklamání. Apple prakticky pouze inovoval stávající model, ke kterému přidal písmenko S a nabídl tak pouze zrychlený procesor s dvěma jádry a inovovaný grafický čip. Další, menší inovací byl fotoaparát, který si po důkladném otestování odborníky odnesl spíše podprůměrné ohodnocení. Pravá revoluce přišla 12. září 2012, kdy byl uveden iphone 5. Přístroj získal větší 4 displej s rozlišením 1136 x 640 bodů a dvou-jádrový procesor architektury Cortex-A15 s 1GB operační pamětí. Ani této předposlední verzi se nevyhnuly menší či větší aféry. Prvním byl únik informací o skutečné ceně hardwaru, použitého při výrobě telefonu. Na světlo vyšly informace, že výrobní cena je čtyřnásobně nižší, jak cena prodejní. Dalším neduhem byl materiál, ze kterého je iphone 5 6\n14 zpracovaný. Apple poprvé použil eloxovaný hliník a ten se projevil, jakožto velmi měkký a nepříliš vhodný materiál. Při testech se mimo jiné zjistilo, že černá hliníková záda nejsou probarvená a při poškrábání se odhaluje skutečná stříbrná barva hliníku. Není tedy překvapením, že iphone 5 se již nestal tak fenomenálním prodejním trhákem, jako předchozí verze. Prozatím nejnovějším počinem Applu je trošku pozměněná logika uvádění nových modelů. Jelikož od uvedení posledního modelu uplynula již poměrně dlouhá doba, začal nový ředitel společnost Tim Cook plánovat, jak změní stávající model, aby donutil své zákazníky k upgradu. Jelikož byl stávající model poměrně oblíbený a vyhlídky na prodejní trhák ve formě nového modelu se začaly zahalovat hustými mračny, rozhodl se Apple, že výrobu hliníkového iphonu ukončí. Místo něj došlo k uvedení dvou nových modelů. iphone 5C, který suploval levnější variantu klasického hliníkového iphonu 5, avšak vybaveného barevnými polykarbonátovými kryty a zcela novým modelem iphone 5S, který z hlediska designu nepřinesl nic nového, ovšem z hlediska výbavy došlo k zcela inovativnímu řešení ve formě čtečky otisků prstů, díky kterému lze telefon odemykat bez použití gest či hesel. Stejné ověřování funguje i v AppStore, kde je možné ověřit identitu kupujícího na základě otisku prstu. Vylepšen však byl také hardware, Apple přišel s 64 bitovou architekturou procesoru, který nově nazval co-procesor. Ta snoubí výkon klasického mobilního procesoru s odděleným čipem zajišťující dohled nad polohou celého mobilního přístroje. Nutno dodat, že po smrti Steva Jobse to nemá Apple jednoduché a se sílící konkurencí bude stále těžší prosadit své výrobky a neudělat přitom fatální chyby. Obrázek 2: Přehled UI jednotlivých verzí ios [převzato z Google.com] 7\n15 Windows Phone Historie chytrých telefonů obsahující operační systém Windows není dlouhá a ani bohatá. Windows je s tímto systémem znám spíše coby Windows Mobile, který veřejnost už zcela jistě poznává. Windows Phone je systém, který však není s Windows Mobile zpětně kompatibilní. Jedná se o kompletně nově navržený operační systém včetně aplikačního vybavení. Píše se 21. říjen 2010, kdy Microsoft uvádí zcela nový a svým způsobem i revoluční systém kombinující velmi nízké hardwarové nároky a jednoduchý vzhled, kterému samotné vedení společnosti říká Metro. Základem domovské obrazovky jsou dlaždice, z nichž každá nese nějakou informaci, propojenou s danou funkcí. Microsoft již zkraje oznámil, jaké požadavky musí telefony s tímto operačním systémem splňovat. Není tedy překvapením, že jsou si jednotlivé modely telefonů až nápadně podobné. Využití OS Windows Phone v Česku doprovází mnoho problémů. Integrovaný vyhledávač Bing nebyl ještě donedávna zcela uzpůsoben pro tuzemské využívání a tak byly některé výsledky neuspokojivé. Problémem mohlo být i samotné zaregistrování přístroje včetně propojení s tržištěm aplikací, který Microsoft pojmenoval Market Place, později stroze Store. První verze systému označená číslem 7 neobsahovala některé základní funkce, kterými konkurence již dávno disponovala. Microsoft však na některé problémy velmi brzy reagoval a uvolňoval pravidelné systémové aktualizace (verze 7.5). Velkou devizou mobilního systému od MS, je ideální spojení s podnikovou sférou. K dispozici tak je mobilní verze plnohodnotného kancelářského balíku Office včetně napojení na cloudové uložiště SkyDrive (nově přejměnované jako OneDrive). Perfektní spojení s Exchange, Dynamics a SharePoint z tohoto systému dělá velmi zajímavou alternativu pro podnikové využití. Významné vylepšení systému přišlo až po téměř dvou letech, kdy MS oznámil verzi 7.8, které přineslo nový design UI a výrazně větší počet kvalitnějších aplikací. Nejnovější verze, která staví na odlišné architektuře, je značena číslovkou 8 s kódovým označením Apollo. Tato verze systému je zpětně nekompatibilní a proto nebude možné využívat aplikace napsané pro Windows Phone 7. Tento krok vyvolal značné vášně a pro mnoho krajních zastánců tohoto systému, to byla poslední kapka do poháru trpělivosti. Jelikož je mobilní divize Microsoftu řízena lidmi, kteří dokáží uznat chybu, přichází tato divize v krátké době s několika důležitými aktualizacemi. Samotný Windows Phone 8 je prakticky třetí generací mobilního OS od Microsoftu. Představen byl koncem října Jedná se o náhradu Windows CE s jádrem NT, ovšem bez zajištěné zpětné kompatibility. V prvotních verzích byl systém velmi omezený a vzhledem k vlažným prodejům se MS rozhodl vydávat objemné systémové aktualizace, které měly po vzoru konkurence, přidávat 8\n16 některé již dávno rozšířené funkce. Za nejdůležitější aktualizaci můžeme považovat NDR 2, která začátkem července 2013 přinesla FM rádio, propojení s Google službami (snaha přetáhnout uživatele Androidu byla více než patrná), vyřešení problémů s dočasnými soubory, které často ukrojily i několik GB z vnitřní paměti. Vylepšen byl výkon a stabilita systému, jako celku. V době, kdy vznikala tato diplomová práce, se hojně hovoří o největší aktualizaci od samotného vzniku mobilního Windows. V červenci roku 2014 přijde oficiální navýšení systému na verzi 8.1, který přinese několik zásadních novinek, mezi které bude patřit notifikační centrum, podpora VPN, možnost změnit si tapetu (dosud šlo měnit pouze barvu dlaždic), nová hlasová asistentka (po vzoru Siri z ios), přímá podpora čtyř jádrových procesorů či fullhd displejů. Inovovaný systém by měl nést název Cyan. Obrázek 3: Souhrnné zobrazení domovských stránek nejrozšířenějších mobilních OS současnosti [převzato z Google.com] 9\n17 Úvod do vývoje mobilních aplikací Vývoj pro mobilní telefony, jak již zaznělo v úvodu této práce, je často mnohem obtížnější procedura, než obdobný vývoj pro desktopové platformy. U mobilních zařízení telefonů či tabletů, je nutné brát v potaz velmi omezené portfolio zdrojů. Předně, mobilní zařízení mají často omezenou kapacitu paměti či slabší výpočetní schopnost danou neplnohodnotnými procesory a grafickými čipy. Architekturu mobilních procesorů nelze s těmi desktopovými srovnávat. Dnešní procesory mobilních telefonů a tabletů mají na první pohled vysoké hodnoty taktovací frekvence. Není neobvyklé, že hodnotnější mobilní telefony obsahují i čtyřjádrové procesory s minimální frekvencí 1,5 GHz a k tomu vysoce výkonné grafické čipy určené k hraní i těch nejnáročnějších her. Takový procesor však z hlediska výrobní technologie, velikosti cache paměti, ale i schopnosti odvádět teplo, nebude nikdy přímým konkurentem klasických procesorů ve stolních počítačích či noteboocích. Při programování aplikací a tedy i zmiňovaných graficky náročných her, je třeba brát v úvahu omezenou kapacitu baterie telefonu. Je tedy nutné, aby byla aplikace dokonale optimalizovaná. Není žádoucí, aby díky své náročnosti tyto aplikace zamrzávaly, padaly, či se například vůbec nespustily. Ranné programování pro Android toto bohužel velmi dobře zná a tak je Android také známý jakožto roztříštěný systém, jehož aplikace nejsou vždy zcela spolehlivé. S posledními verzemi systému toto tvrzení naštěstí ustupuje, ovšem bezpečnostní politika Google je v tomto směru stále trochu nešťastná a tržiště s aplikacemi, které je souhrnně nazýváno Obchod Play kypí stovkami až tisícemi nekvalitních či záměrně škodících aplikací, které nezkušenému uživateli mohou poměrně závažně ublížit. V tomto směru má oproti konkurenci Google stále co dohánět. Základním předpokladem pro vývoj aplikací je znalost vyššího programovacího jazyka. ios sází na jazyk Cocoa, za jehož názvem se skrývá objektové C (Objective C), které je vlastně klasickým jazykem C doplněným o podporu objektů. Programátoři mají tento programovací jazyk velmi rádi, protože aplikace napsaná pro iphone bude bez jakýkoliv problémů stejně dobře fungovat také na ipadu či samotném OS X. Windows šel vždy svojí cestou, programování pro Windows znamenalo téměř vždy znalost C# či.netu. V současnosti nabízí Microsoft několik cest vývoje aplikací pro svůj mobilní operační systém. Nejznámějším je platforma Silverlight, která najde ve spojení s XNA frameworkem využití i v jednoduchých hrách pro XBOX. Operační systém Android, o kterém tato práce pojednává, sází na výhody i nevýhody nejrozšířenějšího multiplatformního jazyka Java. Tento jazyk je mezi vývojáři střídavě na vrcholu i samém dnu. Z jazyka určeného pro programování jednotlivých pracích 10\n18 cyklů automatických praček se stal jazyk, který dnes nalezneme téměř všude. Jeho obrovskou výhodou je snadná přenositelnost a široké spektrum využití. Samotný jazyk Java by nestačil a tak pro přímý vývoj pro Android využíváme specifický framework, který se souhrnně nazývá Android SDK. Ten obsahuje potřebné soubory, ze kterých vývojář sestaví vizuální komponenty aplikace. Abychom mohli psát kvalitní aplikace, je nutné poznat samotný operační systém. Nyní se tedy soustředím pouze na Google Android, o kterém tato práce pojednává. Architektura OS Android Definovat operační systém lze jako spojnici mezi hardwarem a uživatelem. V dnešní době se odvažuji tuto definici jemně zpochybnit. Jistě, operační systémy nám zprostředkovávají práci s CD mechanikou, pevným diskem či jinými komponentami v počítači. V době, kdy tu podobné systémy nebyly, se však počítače ovládaly specifickými příkazy v terminálu. Z dnešního uživatelského pohledu to postrádalo značné pohodlí, však ovládání takového sálového počítače bylo jen pro hrstku vyvolených. Operační systém dnešního chytrého telefonu není jen spojnicí hardwaru a uživatele. Je to doslova ekosystém poskytující neskutečné množství funkcí, informací a možností. Uživatel, který zapne svůj chytrý mobilní telefon často ani neví, jaká práce se skrývá za všemi činnostmi, které jsou tak podstatné pro to, aby telefon správně fungoval. Dnešní smartphone je velmi podobný klasickému stolnímu počítači. Při zapnutí se aktivuje zavaděč (bootloader) a započne start operačního systému. V prvních chvílích bývá operační systém doslova paralyzován. Shromažďuje informace o jednotlivých periferiích v telefonu interní paměti ROM, operační paměti RAM, procesoru, baterii, apod. Po plném zavedení operačního systému započne čtení informací o aplikacích, které si uživatel nainstaloval. Dalo by se říci, že historie se opakuje. Stejně jako v minulosti, čím výkonnější počítač, tím rychlejší start systému. I v mobilních telefonech existuje pomyslné minimum, které garantuje pohodlnou použitelnost daného operačního systému. První mobilní telefony s Androidem byly často osazeny velmi slabým hardwarem. Samotný systém Android nebyl zpočátku tak náročný, jako dnes, ovšem i přesto byly problémy se stabilitou systému velmi časté. 11\n19 Architektura operačního systému Android se skládá z celkem pěti vrstev. Každá vrstva provádí různé operace a vystupuje víceméně samostatně. V praxi však dochází ke spolupráci jednotlivých částí a vrstvy tímto nejsou mezi sebou striktně odděleny. 2 Členění vrstev architektury OS Android Obrázek 4: Architektura OS Android [převzato z Google.com] Linux kernel Základní vrstvou architektury bývá u operačních systémů tzv. kernel (jádro). Funkce kernelu spočívá v zavedení abstrakce mezi hardwarovou a softwarovou částí. Během startu operačního systému je tento kernel zaveden do operační paměti RAM a v takové chvíli má již plnou kontrolu nad celým operačním systémem. Libraries Tato část architektury zahrnuje kompletní správu knihoven potřebnou při vývoji aplikací. Jednotlivé knihovny zastávají předem vymezené funkce. Uveďme výčet těch nejzákladnějších: SQLite knihovna obsahující relační databázi SSL knihovna pro podporu využívání šifrovaného protokolu zejména v internetových aplikacích SGL základní knihovna sloužící pro 2D grafiku 2 UJBÁNYAI, Miroslav. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012, s. 17. Průvodce (Grada). ISBN\n20 Android.widget knihovny podporující prvky uživatelského rozhraní (tlačítka, seznamy, apod.) Android Runtime Tato vrstva obsahuje virtuální stroj DVM (Dalvik Virtual Machine) a základní Java knihovny. Virtuální stroj Dalvik byl vyvíjen od roku 2005 speciálně pro Android společnosti Google pod vedením Dana Bornsteina. DVM má registrově orientovanou architekturu a využívá základních vlastností linuxového jádra, jako je například koordinace běžících procesů, správa paměti nebo práce s vlákny. Nový virtuální stroj přišel na svět, jelikož programátoři, kteří vyvíjeli aplikace pro Android, toto čin prostřednictvím jazyka Java, jehož knihovny jsou licencovány jako open source, avšak samotný virtuální stroj (JVM), který slouží pro překlad programu do spustitelné podoby, již volně šiřitelný není. Dalším důvodem vzniku DVM bylo optimalizovat virtuální stroj pro potřeby mobilních zařízení, tudíž hlavní roli hrál výkon spolu s úsporou energie. Obsah knihoven Java lze téměř srovnat s platformou Java SE (Standard Edition), jejímž základem jsou JVM, API knihovny základních funkcí a API knihovny pro vytváření klientských desktopových aplikací, s tím rozdíle, že ATW a Swing byly u OS Android nahrazeny knihovnami pro tvorbu uživatelského rozhraní a přibyly také knihovny Apache pro práci se sítí. Samotné aplikace pro Android jsou programovány v programovacím jazyce Java, následně překládány do Java byte kódu, a nakonec do mezikódu pomocí Dalvik kompilátoru. Výsledný byte kód je spuštěn na DVM. Každá taková aplikace je samostatný proces s vlastní instancí DVM 3 Application Framework Pro programátory se jedná zřejmě o jednu z nejdůležitějších vrstev. Aplikační rámec nabízí přístup k nejrůznějším službám. Ty lze poté využít přímo ve svých aplikacích. Díky těmto rámcům mohou aplikace přistupovat k nejrůznějším částem systému jako např. číst stav baterie, používat samotný hardware telefonu či spouštět jiné aplikace na pozadí. Mezi důležité aplikační rámce patří: Notification Manager zobrazuje stavový řádek s vlastními upozorněními. Content Providers pracuje s obsahem jiných aplikací SMS zprávy, telefonní seznam, apod. Activity Manager má na starosti životní cyklus aplikace, tedy start, běh i terminace. View System nabízí prvky uživatelského prostředí jako tlačítka, textová pole, apod. 3 UJBÁNYAI, Miroslav. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012, s. 19. Průvodce (Grada). ISBN\n22 Obrázek 5: Typy mobilních aplikací [převzato z meltmedia.com] Anatomie aplikací pro OS Android Systém Android využívá velmi podobné koncepce, jako běžný desktopový operační systém. Aplikace, které vývojář naprogramuje, se vyznačují stejnými specifiky, jako ty, které jsou určeny pro dospělý operační systém uvnitř stolních počítačů. Aplikace sestávají z následujících komponent: Aktivity jedná se o základní stavební jednotku určenou k tvorbě uživatelského rozhraní. Tyto aktivity lze chápat jako analogii dialogů či oken aplikací pro běžné operační systémy, které známe z desktopů. Dodavatelé obsahu základním posláním této komponenty je poskytování obsahu všem aplikacím v systému. U této komponenty dochází k základním pracem s daty, zejména k ukládání a načítání. Služby Aktivity a dodavatelé obsahu jsou entity s krátkou životností a lze je kdykoliv vypnout. Služby jsou oproti tomu navržené tak, aby, pokud je to potřeba, pokračovaly ve své práci nezávisle na jakékoliv aktivitě. Službu můžete použít k detekci aktualizací RSS zdroje nebo k přehrávání hudby, které pokračuje, dokonce i když už byla příslušná ovládací aktivita uzavřena 4 Záměry jedná se o systémové zprávy, které upozorňují na výskyt nějaké události tím, že změní hardwarovou konfiguraci, či ukončí nějakou další aplikaci. Pro lepší představu lze záměru nadefinovat určitě postupy událostí, které budou reagovat 4 MURPHY, Mark L. Android 2: průvodce programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 23. ISBN\n23 v závislosti na poloze systému, času, či stavu baterie. Je tedy možné vytvořit záměr, který omezí maximální nastavení jasu displeje poté, co kapacita baterie klesne pod 15 %. Notifikace (oznámení) Při vývoji operačního systému Android bylo nutné zkonstruovat místo, kde se budou soustřeďovat veškerá systémová upozornění. Android šel svojí cestou a tak byla vytvořena tzv. notifikační lišta. Nejsvrchnější část displeje, která zahrnovala ukazatele času, síly signálu či připojení, ale třeba také příchozí/zmeškaná volání, či SMS. Jednoduchým tahem dolů, bylo možné lištu vysunout a tím získat podrobný přehled o stavu všech událostí. Výrobci se později rozhodli prázdné místo v liště využít pro ovládací prvky displeje, aktivaci/deaktivaci Wi-Fi, vibračního zvonění, atp. Existují tři techniky pro zobrazení oznámení toast notifikace, oznámení ve stavovém řádku a oznámení formou dialogového okna: Toast oznámení Tento typ oznámení se objeví na pracovní ploše okna. Zpráva oznámení vyplní pouze tolik prostoru, kolik zabere samotný text oznámení. Oznámení automaticky zmizí a nepřijímá žádné interakce od uživatele. Tento způsob zobrazení zprávy lze vygenerovat jak z aplikace běžící na popředí, tak i pomocí služby běžící na pozadí. Zpráva bude vypadat vždy stejně. Oznámení je vhodné použít pro zobrazení krátké zprávy, jako např. Soubor uložen, nebo v okamžiku přijetí nového u, či SMS. 16\n24 Obrázek 6: Ukázka toast notifikace [z vlastního zdroje] Oznámení ve stavovém řádku Při tomto způsobu oznámení se do stavového řádku přidá ikona aplikace a rozšíří se seznam oznámení o naši zprávu. Oznámení může být identifikováno také pomocí zvukové či světelné signalizace (LED diodou), nebo pomocí vibrace zařízení. Tento druh oznámení je ideální, když aplikace pracuje na pozadí a služba musí informovat uživatele o vzniklé události. Potřebujeme-li upozornit uživatele na událost, která nastane, zatímco je aktivita stále v centru pozornosti, je vhodnou volbou právě tento typ upozornění. Oznámení formou dialogového okna Při tomto způsobu podání oznámení, se uživateli zobrazí dialogové okno. Toto okno se pro zobrazení zprávy používá u činností, které přímo souvisejí s právě aktivní aplikací. Vhodné použití je nasnadě v případě zobrazení zprávy, která následně vyžaduje potvrzení od uživatele (např. použitím tlačítek OK, nebo storno). 5 Životní cyklus aplikace Aplikace vyvíjené pro mobilní operační systém Android mají rozdílná specifika od běžných tzv. desktopových aplikací. Předně, androidí aplikace nemá žádnou kontrolu nad svým vlastním životním cyklem. U těchto aplikací je tedy nutné brát na zřetel změny stavu a jejich 5 MURPHY, Mark L. Android 2: průvodce programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 39. ISBN\n25 adekvátní řešení. Zejména pak předčasné ukončení či zamrznutí. Každá aplikace, kterou v systému Android spustíme, běží ve svém vlastním procesu. Ten je spuštěn pomocí virtuálního stroje Dalvik. Náležitosti každé aplikace, tedy alokování paměti či podpůrné procesy, jsou řešeny výhradně za běhu. Systém Android je nastaven tak, aby v případě zahlcení operační paměti automaticky ukončoval aplikace, které uživatel dlouhodobě nevyužil. Rozhodnutí o ukončení aplikace je úzce spjato se stavem jednotlivých komponent procesu. Je více než diskutabilní, zda jsou aplikace pro čištění operační paměti přínosné. Životní cyklus aktivity Aktivita se v průběhu svého života může nacházet ve třech základních stavech - může být na popředí a mít uživatelský vstup, může být pouze viditelná, nebo může být pozastavená na pozadí. Při přechodu aktivity mezi stavy jsou volány systémová zpětná volání tzv. callbacky. Tyto callbacky vymezují jednotlivé stavy aktivity a definují její životní cyklus. Tento cyklus je zobrazen na následujícím obrázku 6 Obrázek 7: Životní cyklus aktivity [převzato z abclinuxu.cz] 6 KRYPTA, Tomáš. Vyvíjíme pro Android tvoříme aktivity. In: KOSEK, Jiří. [online] [cit ]. Dostupné z: 18\n26 OS Android vyznává filozofii, že u většiny mobilních zařízení jsou zdroje (paměť, baterie, výkon procesoru, atp.) omezeny a stanovuje mechanismy pro zachování těchto zdrojů. Tyto mechanismy jsou patrně v životním cyklu aktivity, který definuje stavy nebo události, jimiž aktivita prochází od okamžiku, kdy byla vytvořena, až po její dokončení. Každá aktivita reaguje na tyto metody: oncreate metoda je volána při vytvoření aktivity onstart metoda je volána, pokud se uživatel rozhodne vrátit do aktivity onresume metoda je volána, když aktivita komunikuje s uživatelem onpause metoda je volána, pokud dojde uživatelem k přesunu do jiné aktivity ondestroy metoda je volána, pokud dojde v rámci aplikace k ukončení aktivity onrestart metoda je volána, pokud je aktivita zastavena a je potřeba ji obnovit Jelikož v OS Android není zaručen běh procesů aplikace, zvláště pak u aplikace, jež má aktivity na pozadí, a tudíž u ní může dojít k sestřelení jejího procesu, je potřeba si stav aktivity uložit, jelikož v paměti procesoru se po sestřelení aplikace její stav již nenachází. Pokud tak neučiníme a aplikaci opětovně spustíme, uživatelsky zadaná data nebudou zachována. Automaticky jsou ukládány pouze stavy uživatelského rozhraní, tedy např. pole ve formuláři, avšak informace z instančních proměnných se ztratí. Pro uložení těchto proměnných lze využít datová úložiště typu klíč-hodnota, či jednoduchou SQLite databázi anebo externí soubor. 7 7 UJBÁNYAI, Miroslav. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012, s. 41. Průvodce (Grada). ISBN\n27 Vlákna a procesy Pokaždé když je spuštěna aplikační komponenta a aplikace, kde je komponenta definována, nemá vlastní proces, je vytvořen proces nový, obsahující jedno vlákno, ve kterém implicitně běží všechny komponenty aplikace. Pokud je spuštěna nová komponenta, pro jejíž aplikaci již existuje proces, je spuštěna již v existujícím hlavním vlákně (a procesu) aplikace. Toto chování však může být explicitně změněno programátorem a každá komponenta tak může běžet ve vlastním procesu. Nastavení procesů pro aplikaci a její komponenty je prováděno v manifestovém souboru aplikace pomocí atributu android:process. Priorita procesů Android se snaží udržet každý proces spuštěný co nejdéle. Většinou je ale postupem času nutné proces ukončit a uvolnit tak paměť procesům důležitějším. Výběr procesu pro ukončení při nedostatku paměti se řídí podle priority procesu. Procesy s nejnižší prioritou jsou ukončeny nejdříve a procesy s prioritou nejvyšší se snaží systém udržet co nejdéle. Existuje pět priorit procesu: 1. Proces na popředí (Foreground process) proces, potřebný pro aktuální činnost uživatele. Jedná se například o proces, ve kterém běží právě zobrazená aktivita nebo vázaná služba, ke které je právě zobrazená aktivita připojena. Tyto procesy jsou z důvodu uvolnění prostředků ukončovány jen zřídka. 2. Viditelný proces (Visible process) proces, ve kterém neběží žádná komponenta na popředí, ale přesto může ovlivňovat to, co uživatel vidí na displeji. Jedná se například o proces, ve kterém běží částečně viditelná aktivita. 3. Proces služby (Service process) proces, ve kterém běží spouštěná služba a který nespadá do žádné z vyšších kategorií. Proces přímo neovlivňuje to, co uživatel právě vidí na obrazovce. Může v něm například běžet služba pro přehrávání hudby, nebo služba, řídící stahování dat z internetu. 4. Proces na pozadí (Background process) proces, ve kterém běží pozastavené aktivity. Tyto procesy nemají přímý vliv na interakci mezi uživatelem a zařízením. Zpravidla jich v jednom čase existuje velké množství. Jako sekundární kritérium pro výběr procesu, který bude při nedostatku prostředků ukončen, slouží seznam naposled použitých aktivit (LRU last recently used). Ukončení procesu uživatel zpravidla nevnímá, protože stav aktivit, které v něm běží, je před ukončením uložen a při novém startu aktivity obnoven. 20\n28 5. Prázdný proces (Empty process) proces, ve kterém neběží žádná aplikační komponenta. Tyto procesy jsou udržovány pouze z důvodu rychlejšího startu komponent aplikací. Vlákna Pro každou spuštěnou aplikaci je vytvořeno hlavní vlákno. Toto vlákno se často stará o vykreslování a reakce na události uživatelského prostředí. Proto je někdy souhrnně nazýváno vlákno uživatelského prostředí (UI thread). Všechny komponenty jednoho procesu jsou implicitně spouštěny v tomto vlákně. Jakékoliv náročnější operace v UI vlákně mohou zpomalit odezvy UI a znepříjemnit tak uživateli interakci s aplikací. Je proto vhodné všem náročnějším operacím vytvářet vlastní vlákna, a to explicitně nebo pomocí asynchronní úlohy. Programátor by měl zabezpečit, aby UI vlákno nebylo blokováno a aby ke komponentám UI nebylo přistupováno z jiného, než hlavního (UI) vlákna. Pracovní vlákna vytvářená programátorem jsou implementována pomocí třídy Thread. 21\n29 Android Manifest AndroidManifest.xml je soubor uložený v kořenovém adresáři specifikující parametry dané aplikace. Tedy jméno, verzi, komponenty, systémová práva, atp. Tento soubor je při vývoji aplikace velmi důležitý a systém z něj pozná, jaké komponenty má k dispozici. Struktura souboru musí být vždy jednoznačně dána, patří do ní následující komponenty: 1. Název balíku aplikace, který slouží jako unikátní identifikátor 2. Deklarace použitých komponent (aktivity, poskytovatelé obsahu, třídy, atp.) 3. Deklarace oprávnění aplikace (používání periferií, jako GSM modul, paměťová karta, apod.) 4. Deklarace minimální úrovně API (stanovuje, na jaké verzi OS Android bude aplikace spustitelná) 5. Seznam knihoven, které budou s aplikací propojeny Obrázek 8: Ukázka manifestu ve formátu XML [z vlastního zdroje] Manifest je možné naplnit téměř 30 elementy, z nichž každý obsahuje různé atributy. Jsou však určité elementy i atributy, na které se vztahují určitá pravidla Elementy Elementy <manifest> a <application> musí být deklarovány pokaždé. Prvek manifest je navíc elementem s nejvyššími přístupovými právy (tzv. root). Další elementy mohou být obsažený vícekrát, či mohou chybět. Určité elementy jsou považovány za stavební prvky souboru a jejich absence může mít vážný dopad na funkčnost. Atributy Opět platí tvrzení, že určité atributy jsou povinné a jejich neuvedení by znamenalo nefunkčnost aplikace. 22\n30 Přístupová oprávnění Většina aplikací, která si uživatel stáhne do mobilního telefonu, obsahují určitá oprávnění, která musí uživatel před započnutím instalace odsouhlasit. Aplikace může přistupovat na paměťovou kartu, do telefonního seznamu, či aktivovat fotoaparát, nebo GPS. Tato oprávnění se definují právě v Manifestu. Příkladem mohou být následující oprávnění: android.permission.camera aplikace může používat fotoaparát. android.permission.nfc aplikace získá přístup k I/O operacím využívající NFC technologii. Jakmile jsou oprávnění v Manifestu uvedena a aplikace je instalována do zařízení, Android informuje uživatele, která oprávnění aplikace vyžaduje. V případě, že oprávnění je uživatelem uděleno, aplikace může využívat chráněné sekce. Pokud však oprávnění nedostane, pokusy o přístup do chráněných sekci selžou, aniž by o tom byl uživatel informován. 8 Knihovny Každá aplikace, kterou vývojář naprogramuje, bývá propojena s výchozí knihovnou v OS Android. Ta v sobě integruje balíčky pro tvorbu tříd. Tyto balíčky jsou často umístěny v jiných knihovnách a tak je nutné v Manifestu uvést, ze kterých knihoven tyto balíčky vývojář čerpal. Pro tyto účely slouží element <uses-library>, který obsahuje další atributy, díky nimž lze knihovnu pojmenovat a také označit, zda bude knihovna aplikací vyžadována, či nikoliv. Úrovně API (API Level) Úroveň API má na starosti základní prvky kompatibility vytvořených aplikací. Na rozdíl od konkurenčních mobilních platforem, je nutné při vývoji aplikace pro Android definovat jednotlivé úrovně, které bude aplikace splňovat. Tyto úrovně nejsou nic jiného, než jednotlivé verze OS Android. Zatímco aplikace vytvořená pro ios funguje stejně dobře na iphonu i na ipadu, podobná aplikace konstruovaná pro Android může v odlišných verzích činit potíže. API úroveň, kterou reprezentuje celé číslo, obsahuje jednotlivé sady balíčků, tříd, elementů a atributů pro deklaraci Manifestu, záměrů či přístupových oprávnění. Rámec API je navržen tak, aby u API s vyšším číslem byla zajištěna kompatibilita s nižšími čísly a tedy staršími verzemi OS 8 MURPHY, Mark L. Android 2: průvodce programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 46. ISBN\n31 Android. Nejnovější verze systému Android Kit Kat má API úroveň 18. Aplikace s deklarovaným API Level 17 bude plně kompatibilní i se starší verzí, tedy např. Ice Cream Sandwich, Gingerbread, či Froyo, apod. Obrázek 9: Přehled jednotlivých verzí OS Android a jemu odpovídajících API úrovní [převzato z Android Developer] 24\n32 Nástroje pro vývoj v operačním systému Android Android SDK využívá programovací jazyk Java, podobně jako Java Standard Edition (J2SE), nazývaný Android Java Library. To je obrovská výhoda pro vývojáře, kteří se již seznámili s rodinou jazyků C. Syntaxe je prakticky stejná jako u Javy. Zvláště, pokud jde o operandy, selekce, iterace, práci se soubory aj. U konkrétnějších tříd a balíků se používají jiná jména, která nejsou podobná Java edici, jako například aktivity třídy a třídy View. Chceme-li vytvořit aplikaci pro Android, potřebujeme se ujistit, že vývojové prostředí má Javu ve verzi 5 nebo vyšší. Dnešní Java 6 je stabilní a často není žádný důvod, proč tuto verzi nevyužít. Vývojové prostředí Java je vhodné pro nejrůznější typy operačního systému počítače, jelikož je Java nezávislá na operačním systému. Eclipse Vývojových nástrojů je v současné době několik, mezi nejvyužívanější patří Eclipse. Jedná se o open source vývojovou platformu, která je pro většinu lidí známá jako vývojové prostředí (IDE) určené pro programování v jazyce Java. Flexibilní návrh této platformy dovoluje rozšířit seznam podporovaných programovacích jazyků za pomoci pluginů, například o C++ nebo PHP. Právě pluginy umožňují toto vývojové prostředí rozšířit například o návrh UML, či zápis HTML nebo XML. Oproti ostatním vývojovým prostředím v Javě, jako například Netbeans, je filozofie Eclipse úzce svázána právě s rozšiřitelností pomocí pluginů. V základní verzi obsahuje Eclipse pouze integrované prostředky pro vývoj standardní Javy jako kompilátor, debugger atd., ale neobsahuje například nástroj pro vizuální návrh grafických uživatelských rozhraní desktopových aplikací nebo aplikační server všechna taková rozšíření je potřeba dodat formou pluginů. Z tohoto důvodu přímo pod křídly Eclipse vznikly takzvané subprojekty, které zastřešují rozšíření pro jednotlivé oblasti softwarového vývoje v Javě. Tyto subprojekty usnadňují integraci potřebných rozšíření do samotného vývojového prostředí. Eclipse je v současnosti nejpopulárnější IDE pro Javu. 9 Android SDK Komponenta, která je pro vývoj pro OS Android nezbytná, se nazývá Android Software Development Kit (SDK). Ten dodá do prostředí Eclipse nezbytné součásti, bez kterých nelze aplikace vyvíjet. Jedná se tedy o sadu vývojových nástrojů, mezi které patří debugger, knihovny, dokumentace a emulátor, který simuluje chování OS Android v prostředí desktopu. 9 Eclipse - The Eclipse Foundation open source community website. [online]. [cit ]. Dostupné z: https://www.eclipse.org/ 25\n33 Vylepšení SDK jdou ruku v ruce s vývojem celé platformy Android. Je tedy nezbytné tento vývojářský balík neustále aktualizovat. Spustitelné aplikace pro OS Android jsou zabaleny ve formátu.apk a ukládají se do složky /data/app. Tato složka je dostupná pouze pro uživatele s root právy. APK balíček obsahuje také soubory.dex, což jsou kompilované soubory byte kódu z virtuálního stroje Dalvik. Android ADB V softwarovém kitu SDK můžeme nalézt sadu Android Debug Bridge (ADB), která se skládá z klienta a serveru. Ty spolu komunikují a dostupné jsou převážně z rozhraní příkazového řádku. ADB je častým terčem bezpečnostních útoků. V roce 2011 byl zaznamenán problém s prolomením bezpečnostního gesta displeje. U odcizeného smartphone bylo možné při propojení s počítačem vyresetovat uložené gesto displeje jednoduchým skriptem v shellu. Po restartu telefonu poté bylo možné vstoupit do operačního systému a případně páchat další škody. Vývojáři Google včas zareagovali a tuto chybu brzy opravili. V nejnovější verzi Jelly Bean je pak toto gesto nemožné prolomit. Fastboot Další součástí SDK je diagnostický protokol Fastboot, který se používá především k úpravě souborového systému přes USB připojení z hostitelského počítače. Použití tohoto protokolu je podmíněno stavem operačního systému, který se musí nacházet v zavaděči bootloaderu, tedy ve stavu, ve kterém se provádí pouze základní hardwarové inicializace. Po povolení tohoto protokolu bude samotné zařízení schopno přijímat specifické sady příkazů, zasílány přes příkazovou řádku. Fastboot se hojně využívá při tzv. flashování operačního systému. Pokud se uživatel rozhodne vymazat stávající verzi Androidu dodanou výrobcem a nahradit jí alternativní verzí tzv. custom ROM, je u většiny typů mobilních telefonů nutné provést root a nahrát mód, podobný počítačovému BIOS. Tyto operace se provádějí nejčastěji právě přes Fastboot. Android NDK Jedná se o knihovny napsané v jazyce C, či případně jinými jazyky, ovládajícími architekturu ARM či MIPS. Nativní třídy lze volat přímo z kódu v jazyce Java běžícím ve virtuálním stroji Dalvik. Na rozdíl od vývoje aplikaci v Javě na základě prostředí Eclipse IDE, je NDK určeno pro příkazy z terminálu, pomocí kterého je možné aplikace vytvářet, implementovat a ladit. NDK je možné integrovat do Eclipse, ale třeba i do Visual Studia. 26\n35 podporuje většinu dnešních mobilních platforem, zejména tedy Android, ios, Windows Phone, ale také Symbian, Tizen či BlackBerry. Obrázek 10: Architektura nástroje PhoneGAP [převzato z phonegap.com] Oracle ADF Mobile Stále populárnějším nástrojem pro tvorbu tzv. hybridů, je ADF Mobile od Oraclu. Výsledná aplikace je směsicí nativní i webové architektury a obrovskou výhodou je schopnost multiplatformního řešení aplikací. Vývojář tedy v několika krocích vytváří aplikaci jak pro Android, tak i pro ios. Nutno podotknout, že výsledná aplikace je vždy ústupkem za usnadněnou práci i čas. Optimalizace a výkonnost nepatří mezi silné stránky podobných řešení. 28\n36 Obrázek 11: Architektura tvorby hybridních aplikací pomocí ADF Mobile [převzato z oracle.com] Uživatelské rozhraní OS Android Základem pro tvorbu komponent uživatelského rozhraní je specifická třída View. Tato komponenta reprezentuje vymezené oblasti displeje a zodpovídá za vykreslení a případné zpracování dalších komponent. Tato třída je důležitým prvkem, obsahuje totiž podtřídy nazývané Widgets. Tedy interaktivní prvky na obrazovce, kterými lze aplikace ovládat tlačítka, okénka, seznamy, textová pole, apod. Důležitým prvkem, který spravuje rozvržení displeje je třída ViewGroup, ta nabízí různé druhy rozvržení, mezi které může patřit tabulkové, relativní, či absolutní. Při vývoji aplikace je nutné zvážit jaký typ rozvržení definovat, je nutné brát v potaz, že platforma Android je dostupná na široké škále mobilních zařízení, od mobilních telefonů s min. úhlopříčkami 2,8 až po tablety s úhlopříčkami 10 a více palců. Při návrhu uživatelského rozhraní je potřeba také myslet na zařízení, na kterém aplikace poběží, a to z hlediska rozlišení displeje, popř. z hlediska rotace aplikace při rotaci zařízení. Oba výše zmiňované problémy je potřeba v aplikaci zohlednit, aby nedocházelo na určitých typech zařízení k deformaci uživatelského rozhraní, jež bude mít v konečném důsledku neblahý vliv na uživatele, respektive na aplikaci, kterou uživatel díky těmto problémům už 29\n37 nikdy nepoužije. Tyto problémy ovšem nevyvstanou, pokud použijeme zobrazení komponent pomocí rozvržení, místo abychom je zobrazovali přímo na obrazovku 10 Rozvržení obrazovky Volba jednotlivých rozvržení displeje je čistě na vývojáři. Základem by mělo být takové rozvržení, které bude intuitivní pro uživatele a nebude obsahovat mnoho rušivých elementů. Při vývoji nám Android SDK nabídne několik typů rozvržení: 1. Relativní rozvržení v tomto typu lze nadefinovat umístění objektů relativně vůči obrazovce, nebo jiným objektům. 2. Lineární rozvržení lineární uspořádání přidává pro každý objekt typu View jeden řádek, a to buď vertikálně, nebo horizontálně. Vertikální uspořádání umístí jeden objekt na jeden řádek, zatímco při použití horizontálního rozložení jsou všechny objekty zobrazeny v jediném řádku. Lineární rozvržení umožňuje každému objektu View určit váhu, která se řídí relativní velikostí každého z nich v dostupném prostoru. 3. Tabulkové rozvržení umožňuje rozložit objekty pomocí mřížky řádků a sloupců. 4. Absolutní rozvržení je definováno pomocí absolutních souřadnic, které zaručí přesné rozložení komponent. 11 Rotace obrazovky při změně polohy zařízení V současné době je k dispozici ohromná škála zařízení s operačním systémem Android. Některé disponují pouze virtuální klávesnicí, jiné dostaly do vínku klávesnici fyzickou. A právě tato fyzická klávesnice působila zpočátku určité problémy, při jejím vysunutí totiž došlo k otočení obrazovky do horizontální polohy. Některé aplikace na tuto rotaci reagovali kompletní deformací obrazu. Můžeme říci, že vývojáři zapracovali na bezvadné horizontální alternativě svých aplikací teprve nedávno. Změnit polohu obrazovky dokáží samozřejmě i zařízení s virtuální klávesnicí. K tomu jim dopomáhá tzv. akcelerometr. 10,12 UJBÁNYAI, Miroslav. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012, s Průvodce (Grada). ISBN\n38 Chování rozvržení, v rámci změny orientace lze definovat pomocí atributu android:screenorientation náležícího v souboru AndroidManifest.xml elementu <acitvity>. Atribut android:screenorientation může nabývat některé z těchto hodnot: unspecified výchozí hodnota, systém zvolí orientaci automaticky. landscape orientace na šířku (otočení o 90 stupňů vlevo). portrait orientace na výšku. sensor orientace je řízena pohybovým senzorem v závislosti na aktuální poloze celého zařízení. nosensor orientace je určená bez ohledu na fyzickou polohu zařízení UJBÁNYAI, Miroslav. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012, 187 s. Průvodce (Grada). ISBN\n39 Vizuální komponenty systému Android Každá sada nástrojů pro tvorbu grafického uživatelského rozhraní (GUI) nabízí určité základní vizuální komponenty widgety. Tedy popisky, textová pole, tlačítka, apod. V každém vývojovém nástroji si lze zobrazit základní plátno (Canvas), na které vývojář vkládá jednotlivé vizuální komponenty. Android SDK je výjimečný tím, že v závislosti na zvolené úrovni API, poskytne přesné grafické provedení všech těchto komponent tak, aby zapadaly do jednotného designového stylu samotné verze systému Android. K dispozici máme několik komponent, které mohou ozvláštnit naše aplikace. Mezi základní a nejpoužívanější patří následující. Textové popisky Jedná se o nejzákladnější vizuální komponent. Jedná se o textový popis, který nelze žádným způsobem uživatelsky upravit. Jako příklad lze uvést popisek Jméno, vedle kterého se bude nacházet textové pole, kam uživatel doplní příslušné iniciály. V Javě můžeme popisek vytvořit tak, že vytvoříme instanci třídy TextView. Nejčastěji se však popisky tvoří v XML souborech tak, že přidáme do návrhu element TextView s atributem android:text specifikujícím text popisku. Třída TextView má mnoho dalších vlastností týkajících se popisků, jako jsou například následující vlastnosti: Android:typeface specifikuje rodinu písma, které se bude používat pro text popisků. Android:textStyle specifikuje tučné písmo (bold), kurzívu (italic) nebo tučnou kurzívu (bold_italic). Android:textColor specifikuje barvu textu popisků v hexadecimálním RGB formátu. 13 Tlačítka Dá se říci, že tlačítko je zřejmě nejčastěji využívanou komponentou nejen v systému Android, ale také i jiných mobilních operačních systémech. Z hlediska jazyka Java se jedná podtřídu třídy TextView. Komponenta Button (tlačítko) reaguje na uživatelský stisk provedením nějaké předem nadefinované posloupnosti příkazů. Tlačítko můžeme vytvořit opět pomocí XML souboru. 13 MURPHY, Mark L. Android 2: průvodce programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 49. ISBN\n40 Použití tlačítka na návrhovém plátně spolu s deklarací v XML můžeme vidět na tomto obrázku: Obrázek 12: Deklarace tlačítka včetně jeho vlastností ve zdrojovém kódu [z vlastního zdroje] Zaškrtávací tlačítka Anglický název CheckBox, tedy zaškrtávací políčko, může mít podobně jako žárovka dva stavy zaškrtnuto či nezaškrtnuto (tedy vypnuto/zapnuto). V Androidu jej implementujeme prostřednictvím třídy TextView. Deklarovat lze také barevnost. Políčko má v programovacím jazyce Java následující metody: ischecked() určuje, zda je políčko zaškrtnuté. setchecked() nastavuje políčko na zaškrtnuto/nezaškrtnuto. Toggle() zaškrtne/odškrtne políčko podobně, jako by operaci provedl sám uživatel. Deklarace je prakticky identická, jako u tlačítek: 33\n41 Obrázek 13: Deklarace zaškrtávacího tlačítka včetně jeho vlastností ve zdrojovém kódu [z vlastního zdroje] Přepínače Velmi podobnou funkčnost mají i tzv. Radiobuttony. Tedy kulaté přepínače, pomocí kterých uživatel volí jednu z několika možností. Seskupení v jeden celek reprezentuje třída RadioGroup. Tato instance označuje množinu přepínačů, jejichž stavy na sobě vzájemně souvisí, což znamená, že lze označit pouze jeden z nich. Deklarace je opět stejná, jako u předchozích dvou komponent. 34\n42 Obrázek 14:Deklarace přepínacího tlačítka včetně jeho vlastností ve zdrojovém kódu [z vlastního zdroje] Obrázky Obrázky lze v systému Android použít pomocí objektů ImageView a ImageButton. První ze jmenovaných je podtřídou třídy TextView, druhý objekt je odvozen ze třídy ImageView. Oba objekty vlastní atribut android:src, jenž specifikuje obrázek zobrazený na obrazovce. Pro ukládání obrázků máme k dispozici tři různé adresáře: 1. res/drawable-hdpi/ 2. res/drawable-mdpi/ 3. res/drawable-ldpi/ Každý z těchto adresářů slouží pro uložení obrázků s různou kvalitou rozlišení. Díky použití tohoto systému lze zlepšit vzhled aplikací, protože v případě nutnosti zobrazit obrázek OS Android sám zvolí, který obrázek podle rozlišení obrazovky použije. 14 V následujícím obrázku lze vidět rozdíl mezi obrázkem vytvořeným z objektu ImageView (hvězdička) a ImageButton (sluchátko). Obrázek sluchátka tímto funguje také jako tlačítko, kterému lze přiřadit instrukci vstoupení do dialeru, tedy do prostředí číselníku. 14 UJBÁNYAI, Miroslav. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012, s Průvodce (Grada). ISBN\n43 Obrázek 15: Rozdíl mezi obyčejným obrázek a tzv. akčním obrázkem, který po kliknutí provede určitou akci [z vlastního zdroje] 36\n44 Úvod do praktické části práce Po nezbytném teoretickém úvodu, bez kterého by bylo velmi obtížné pochopit samotný vývoj na platformě Java, přejdeme plynule do praktické části této diplomové práce. Hlavním cílem této práce je vytvoření aplikace bankovního charakteru, která bude schopná po zadání potřebných parametrů, vypočíst měsíční splátku úvěru včetně celkové částky splatnou bance. Aplikace bude optimalizována pro nejnovější verzi Androidu 4.4 Kit Kat a vyšší. Funkční však bude i na nižších verzích systému. Součástí aplikace je návrh základního layoutu, který deklarujeme ve formátu XML. Jak již zaznělo, samotný vývoj mobilních aplikací pro platformu Android probíhá nejčastěji ve vývojovém prostředí Eclipse, který jsem také již dostatečně popsal v teoretické části této práce. Jedná se o tzv. Host Target vývoj. Tedy typ prostředí, kde samotný vývoj a testování již vytvořené aplikace probíhá na odlišném typu zařízení. Typicky vývoj v počítači a testování v tabletu, či jiném mobilním zařízení. Testovat však lze také přímo v prostředí Eclipse a to díky emulátoru, který představím později. Abychom mohli začít, je potřeba Eclipse dovybavit potřebnými frameworky, které vytvoří kompletní prostředí, vhodné pro vývoj pro platformu Android. Jedná se především o tzv. JDK, SDK a ADT. Java Development Kit (JDK) JDK obsahuje základní nástroje pro vývoj aplikací v Javě. Součástí je Java Runtime Environment, který slouží ke spuštění aplikací a také debugger. JDK ve své nejnovější verzi je vždy dostupný na webové stránce Oracle. Software Development Kit (SDK) SDK obsahuje nástroje potřebné pro samotný vývoj Android aplikací. Součástí jsou jednotlivé API knihovny, patřičná dokumentace a SDK Manager, ve kterém lze specifikovat vývoj pro jednotlivé verze Androidu (2.3, 4.0, 4.1, apod.). Součástí androidího SDK je také emulátor (ADV), ve kterém je možné aplikaci řádně otestovat. Tento emulátor se chová přesně jako fyzický mobilní telefon či tablet se systémem Android. Disponuje veškerými funkcemi, takže je možné nasimulovat nejen příchozí či odchozí hovory, ale také komunikaci s internetem prostřednictvím mobilního internetového prohlížeče. Nejnovější SDK pro Android lze stáhnout na webové adrese developer.android.com. 37\n45 Základní konfigurace SDK: SDK Tools Obsahuje nástroje pro debugging (ddms), testování aplikace, správu Android Virtual Devices (AVD), Android emulátor, analýzu grafického layoutu a další potřebné programy. SDK Platform-tool Obsahuje další důležité nástroje pro vývoj aplikací, které jsou závislé na verzi platformy a jsou aktualizovány při vydání nové verze SDK. Jeden z nástrojů je například Android Debug Bridge, umožňující nahrávat soubory do zařízení. Android SDK platforms Každá platforma SDK se skládá z knihoven, systémového obrazu, ukázkových kódů, skinů emulátoru a jiných zdrojů. Ke kompilaci aplikace a pro nastavení a běh AVD musí být přítomna alespoň jedna platforma. Doporučená konfigurace SDK: USB Driver Komponenta, která je nutná pouze při ladění a testování aplikace nainstalované na zařízení. Potřebné pouze pro platformu Windows. Příklady kódů Obsahuje ukázkové kódy aplikací, které jsou aktuální pro každou platformu. Dokumentace Obsahuje lokální kopii dokumentace pro aktuální Android framework API. Tato dokumentace je také využita ve vývojovém prostředí Eclipse. Plné konfigurace SDK: Google API Knihovny, zpřístupňující rozhraní Google Maps, které je možno použít v aplikacích. Ostatní SDK platformy To je například Market Licensing package, který obsahuje knihovnu ověřující licenci aplikace, zda se nejedná o nelegální kopii. 38\n46 Obrázek 16: SDK Manager sloužící k výběru instalovaného API, pro které chceme vyvíjet [z vlastního zdroje] Optimalizace vývojového prostředí Eclipse Eclipse je primárně určen pro programování v jazyce Java. Jeho nespornou výhodou oproti ostatním vývojovým prostředím je snadná rozšiřitelnost o podporu dalších programovacích jazyků, nebo o vizuální nástroj pro tvorbu graficko-uživatelského rozhraní. Všechny tyto doplňky se do Eclipse instaluji pomocí příslušných pluginů UJBÁNYAI, Miroslav. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012, s. 30. Průvodce (Grada). ISBN\n47 Obrázek 17: Deklarace API úrovně včetně patřičného SDK [z vlastního zdroje] Abychom mohli vytvářet aplikace pro Android, je nutné nainstalovat plugin Android SDK, díky kterému získáme již zmiňovaný emulátor pro testování aplikací. Vývojové prostředí Eclipse je rozděleno interně do různých částí, nazývaných perspektivy. Jedná se o seznam komponent, jejichž rozvržení lze v prostředí uživatelsky upravovat, jakožto i jejich samotný výběr. Perspektiva by měla sdružovat takové komponenty, které se vztahují k jedné problematice. Důležitou součástí je správné a funkční nastavení vývojového prostředí, které usnadní samotný vývoj aplikací. Pro potřeby vývoje pro Android je nutné propojit Eclipse s Android SDK. Propojení je prezentováno pluginem Android Development Tool (ADT), jenž rozšiřuje možnosti Eclipse a umožňuje tím rychlou tvorbu Android projektů. Pomocí ADT programátor obdrží výkonné integrované prostředí s editorem vizuálních aplikací, vlastními XML editory, ladícími panely a tvorbou APK balíčků pro distribuci aplikace UJBÁNYAI, Miroslav. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012, s. 32. Průvodce (Grada). ISBN\n48 Obrázek 18: Rozvržení vývojového prostředí Eclipse [z vlastního zdroje] Tvorba aplikací úvod do softwarového inženýrství Na vývoj mobilních, ale také i počítačových aplikací jsou dnes kladeny stále větší požadavky z hlediska správnosti, spolehlivosti i bezpečnosti. Na druhou stranu od počítačů očekáváme stále vyšší funkčnost, a pokud možnost za co nejméně peněz. Tyto požadavky však jdou v principu proti sobě jestliže například zvýšíme funkčnost produktu, vzroste tím jeho složitost a bude proto obtížnější a dražší dosáhnout požadované spolehlivosti. Odpovědí na potřebu levně vyvíjet bezpečný a současně užitečný software je právě softwarové inženýrství, které zahrnuje tři hlavní oblasti: 1. Management projektu metodologie pro řízení životního cyklu projektu a postupy pro dosažení požadovaného výsledku v požadovaném čase. 2. Techniky pro analýzu, návrh, programování, testování a údržbu softwaru. 3. Výchova softwarového inženýra poskytuje mu základní bázi znalostí, učí ho využívat tyto znalosti v praxi a motivuje ho k vyhledávání informací nových. 17 Samotná disciplína softwarového inženýrství se vyvíjela několik desítek let. V současnosti se z ní stala nepostradatelná pomůcka při vývoji softwarových produktů. Jedním z velmi významných milníků je rozšíření modelovacího jazyka UML, který při současných trendech 17 KŘENA, PH.D., Ing. Bohuslav a Ing. Radek KOČÍ, PH.D. VUT FIT BRNO. Úvod do softwarového inženýrství: Studijní opora [online], s. 6. vyd. Brno, 2006 [cit ]. 41\n49 pro zákaznického vývoje softwaru nabývá na důležitosti. Jak roste složitost vývoje softwarových projektů, objevuje se více a více problémů, kterými mohou být vysoké náklady na vývoj, velká spotřeba času pro jednotlivé projekty či jednoduché zklamání z výsledného produktu, který nesplňoval očekávání zákazníka. Takový stav nazýváme softwarovou krizí. A právě softwarové inženýrství je lékem proti této krizi. Zavedly se nové programovací jazyky, které byly rychlejší, úspornější a jednodušší na osvojení. Programy se tvořily rychleji, s menším počtem chyb a s lepšími možnostmi správy. Problémy při vývoji softwaru Z hlediska vývoje softwaru bývá nejrizikovější přejímka požadavků od zákazníka. Často se jedná o laika, která ve většině případů sám neví, co od aplikace požadovat. Má mlhavou představu, ovšem neví, zda jsou takové představy bez problémů realizovatelné. Mezi nevyhnutelné problémy patří: Poddajnost v případě změny se mění i aplikace, nikoliv naopak. Složitost žádné dvě části nejsou stejné; složitost je zdrojem dalších problémů, jako např. komunikace v týmech; je náročné pochopit všechny stavy systému, problémy s úpravami či rozšířeními, apod. Neviditelnost neexistuje přijatelný způsob reprezentace softwarových výrobků, který by pokryl všechny aspekty. Dokonce ani nejsme schopni určit, co v dané reprezentaci chybí. Ilustrací neviditelnosti je tzv. syndrom 90 % hotovo. Při posuzování hotové části se totiž nevychází z hotového, ale z odpracovaného. Pokud tedy manažer průměrného projektu poprvé od programátorů uslyší, že je již 90 % práce uděláno, může si být jist, že program není hotov ani z poloviny a že hlášení 90 % hotovo uslyší v průběhu řešení projektu ještě mnohokrát. 42\n50 Mezi další problémy během vývoje jakéhokoliv softwaru, tedy i mobilní aplikace můžeme zařadit také: Náchylnost k chybám nejvíce chyb se projeví až za plného provozu (ne při vývoji). Odstraňování chyb vede k návratu v etapách vývoje produktu. Práce v týmu jedním z hlavních zdrojů chyb v programech jsou komunikační problémy. Práce na velkých softwarových projektech se těžko organizuje a plánuje. Problémy plynoucí z práce v týmu ilustrují následující dva postřehy Freda Brookse: Přidáním dalších pracovníků do zpožděného projektu se tento projekt ještě více zpozdí. Napsání překladače Algolu zabere 6 měsíců nezávisle na tom, kolik ho vytváří programátorů. 18 Nízká znuvupoužitelnost při tvorbě softwaru v procesu tvorby softwaru je málo standardů a většinou se software tvoří od začátků. S každým programem se tak vymýšlí už vymyšlené, zatímco jenom málo produktů se sestavuje z už existujících součástí. Tvorba dokumentace čím je projekt větší, tím vyžaduje více dokumentace (roste jak kvantita, tak i rozmanitost). A čím je dokumentace rozsáhlejší a rozmanitější, tím se hůře udržuje její aktuálnost, úplnost i konzistence. Ve velkých vojenských softwarových projektech připadalo 400 anglických slov na každý příkaz v programovacím jazyce Ada. 19 Nejdůležitější částí vývoje každé aplikace je její životní cyklus. Ten definuje etapy vývoje aplikace a pro každou etapu definuje nutné činnosti s potřebnými vstupy a výstupy. Jednotlivé etapy lze vyjádřit procentuálnímu vynaloženému úsilí: Analýza (8 %) Návrh (7 %) Implementace (12 %) Integrace a testování (6 %) Provoz a údržba (67 %) Nejvíce úsilí, tedy časové a finanční představuje fáze provozu a údržby. Je důležité věnovat zvýšenou pozornost úvodnímu vyřčení požadavků na software. Jedině tak lze předejít problémům ve fázi zavedení a provozu softwaru. Počáteční etapy bohužel svádějí k úsporám a k častému ověření přísloví, že lenoch se vždycky nejvíce nadře. 18,20 KŘENA, PH.D., Ing. Bohuslav a Ing. Radek KOČÍ, PH.D. VUT FIT BRNO. Úvod do softwarového inženýrství: Studijní opora [online] vyd. Brno, 2006 [cit ]. 43\n51 Etapy životního cyklu softwaru Analýza a specifikace požadavků je úvodní etapou při vývoji softwarového produktu, ve které se zabýváme požadavky zákazníka na software získáváme je, analyzujeme, definujeme a specifikujeme je, kdy z neúplných a nejasných požadavků zákazníka dostáváme strukturované, jasné a konzistentní požadavky na produkt. Pozornost je třeba věnovat požadavkům samotným a nikoliv jejich realizaci. Součásti této etapy by měla být studie vhodnosti (proveditelnosti), která odpoví na důležitou otázku, zda má smysl se do projektu vůbec pouštět. Dalším možným výsledkem této etapy může býti identifikace možných rizik a jejich analýza. Nezbytným výstupem je plán akceptačního testování (testy, na jejichž základě zákazník produkt převezme - akceptuje). Chybějící specifikace akceptačních testů je zárukou problémů při přebírání hotového produktu zákazníkem. 20 Architektonický návrh navazuje na analýzu požadavků a slouží k ujasnění koncepce systému a k jeho dekompozici. Dekompozice vyžaduje vymezení funkcionality jednotlivých podsystémů a definování vztahů mezi nimi. Podobně jako se při analýze plánuje akceptační testování, tak se při architektonickém návrhu plánuje testování celého systému. Je vhodné naplánovat postup nasazení do provozu, a to včetně zaškolování uživatelů. Podrobný návrh se soustřeďuje na podrobnou specifikaci softwarových součástí, na výběr algoritmů realizujících požadované funkce, na stanovení logické a fyzické struktury dat a na způsoby ošetřování chybových a neočekávaných stavů. Při podrobném návrhu se také plánují práce na implementaci součástí, s čímž souvisí vytvoření požadavků na lidské zdroje a odhad doby trvání včetně nákladů na projekt. Implementace a testování součástí zahrnuje programovou realizaci softwarových součástí, vypracování dokumentace k součástem a otestování implementovaných součástí. Integrace a testování odhaluje chyby, které nebyly možné objevit izolovaným testováním samostatných součástí systému. Objevené chyby jsou samozřejmě opravovány. Testování součástí nelze vynechat s odkazem na to, že už součásti otestovány byly, protože opravou nalezených chyb se do programu mohou zanést chyby nové. 20 KŘENA, PH.D., Ing. Bohuslav a Ing. Radek KOČÍ, PH.D. VUT FIT BRNO. Úvod do softwarového inženýrství: Studijní opora [online], s. 13. vyd. Brno, 2006 [cit ]. 44\n52 Akceptační testování a instalace spočívá v otestování systému uživatelem. Na základě akceptačního testování se pak zákazník rozhodne buď systém převzít nebo při objevení závažnějších nedostatků předat systém zpět k přepracování či doplnění. Provoz a údržba vyžadují průběžné řešení problémů, které s nasazením a používáním softwaru souvisejí. Tato etapa také zahrnuje opravy nalezených chyb, rozšiřování softwaru o nové funkce, či přizpůsobování softwaru měnícím se požadavkům okolí. 21 Analýza a návrh projektu Bankovní kalkulátor Cílem projektu je vytvořit aplikaci, která na základě vyplnění několika textových polí vygeneruje výsledek měsíční splátky úvěru a celkové částky, splatnou bance. Pro bezproblémové provedení algoritmu je nutné zadat tyto údaje: Výše úvěru uvedení částky v celých číslech (např Kč) Roční úrok v procentech uvedení ročního úroku sjednaného úvěru (např. 3,15 %) Doba splácení v měsících výběr z přednastavených hodnot (např. 60 měsíců, maximum je 240) Design aplikace bude postaven na prvcích přístupnosti. Důraz budeme klást na kontrastní barvy a velký font písem. Veškeré funkční části aplikace budou znatelně a logicky rozpoznatelné. Definice vizuálního stylu aplikace V analýze a návrhu mobilní aplikace Bankovní kalkulátor jsem nastínil hrubý vzhled této aplikace. Na základě znalostí tvorby vizuálních komponentů z teoretické části této práce bude jednotlivé rozmístění těchto komponentů realizováno v návrhové části vývojového prostředí Eclipse. Na základě pozdějšího testování veřejností jsem došel k závěru, že standardní HOLO design nahradím graficky příjemnějším layoutem, jehož srovnání lze nalézt na níže uvedeném obrázku. 21 KŘENA, PH.D., Ing. Bohuslav a Ing. Radek KOČÍ, PH.D. VUT FIT BRNO. Úvod do softwarového inženýrství: Studijní opora [online], s. 20. vyd. Brno, 2006 [cit ]. 45\n53 Obrázek 19: Srovnání základního HOLO designu (vlevo) a vylepšeného designu (vpravo) [z vlastního zdroje] Základní layout aplikace Způsob, kterým rozvrhneme komponenty uživatelského rozhraní naší aplikace je prakticky vždy na vývojáři. Existují určitá doporučení, která se vyplatí dodržet. Jednotlivá tlačítka by měla být přiměřeně vzdálená, aby je bylo pohodlné obsloužit i většími prsty. Měla by být dostatečně velká a čitelná. Musíme pamatovat na širokou rozmanitost zařízení s OS Android. Co může vypadat dobře na tabletu, nemusí nutně vyhovovat uživateli smartphonu s 3,5 displejem. Layout lze u OS Android navrhnout buď v programové části na virtuálním plátně či přímo v XML. Tyto postupy lze poté libovolně kombinovat. Nanesením komponenty se vytvoří odpovídající zdrojová část třída, které lze poté udělit nějakou akci. Je tedy možné definovat nejen rozměr tlačítka, ale také stavy, které budou následovat po kliknutí na toto tlačítko. Například: po kliknutí na tlačítko vypočítat se provede výpočet na základě předem stanoveného algoritmu se zadanými hodnotami úvěru. Pro operační systém Android existuje 5 základních typů layoutů: Lineární layout komponenty se organizují v řádcích. Pomocí orientace lze určit, zda se každá další komponenta bude umisťovat na nové řádky, či na řádek jeden. Rámcový layout ideální pro zobrazení jednoho prvku, např. obrázku. Při vložení dalšího prvku dojde k překrytí stávajícího. 46\n54 Tabulkový layout tento typ rozvržení si lze představit jako tabulku obsahující řádky a sloupce. Relativní layout jedná se o rozvržení závislé na rozložení ostatních komponent. Pokud chceme, aby tlačítko OK bylo vpravo, tlačítko Storno vlevo a to vše pod určitým textem, lze tento systém rozložení aplikovat tak, že dojde ke splnění všech podmínek. Takto vzniklý layout je možné kontrolovat nejen na virtuálním plátně, ale je možné si jej spustit také v emulátoru, abychom viděli, jak se jednotlivá tlačítka chovají a zda je rozmístění intuitivní. V prvních chvílích byl vytvořen základní layout, který nabízí přímo SDK. Na základě testování aplikace uživateli byl tento základní design shledán, jako nevyhovující. Byl tedy vytvořen grafický layout, který by vizuálně oddělil jednotlivé funkční prvky aplikace a ta se tak stala více přehlednou. Základní rozvržení grafiky definujeme v XML. Objektem zájmu jsou pomyslné funkční úseky, z nichž každá přidává rozdílnou informační hodnotu. Navržený layout sestává z: Uživatelské části jedná se o horní část obrazovky, ve které uživatel vkládá svá data. Pro vysvětlení jsou v hranatých závorkách uvedeny i měrné jednotky. Po kliknutí na první dvě pole, tedy výše úvěru a roční úrok, je automaticky vyvolána numerická klávesnice. Při implementaci lze zvolit, jaký typ klávesnice se má zobrazit. Vedle numerické se může jednat i o standardní QWERTZ. Uživatel je poté vyzván, aby na klávesnici zadal příslušná čísla. Pokud nezadá žádná, aktivuje se toast upozornění a nevyplněná pole se vybarví červenou barvou. Action části sem můžeme zahrnout pomyslný spouštěč celého algoritmu. Jedná se tedy o tlačítko vypočítat, které vyvolá akci porovnání a validitu zadaných hodnot uživatelem a samotný výpočet, který se zobrazí v poslední části. Výsledkové části nejspodnější třetina layoutu, kde se zobrazují dva výsledky. Zejména tedy číselné hodnoty měsíční splátky a také celkové částky splatné bankovnímu ústavu. Jedná se to částku úvěru, navýšenou o úroky. Vedlejší poplatky, jako např. pojištění úvěru, či poplatky za vedení účtu, nejsou v tomto kalkulátoru obsaženy. 47\n55 Obrázek 20: Výpočet splátky a ukázka upozornění na nevyplněné hodnoty [z vlastního zdroje] Implementace Nejdůležitějším milníkem při vývoji softwaru je přímý akt programování, kterému předchází nejen analýza a návrh. Tedy co a jakým způsobem vytvoříme. Ale také studie proveditelnosti, která v našem případě však postrádá smysl. Při vývoji jedné, velmi jednoduché aplikace je většinou zbytečné postupovat všechny etapy životního cyklu. Často postačí, když si uvědomíme, co má aplikace dělat a jakým způsobem jí chceme vytvořit. Velmi zajímavým názorem bývá fakt, že nejdůležitější částí z celé implementace je vymyšlení samotného algoritmu. V našem případě tedy sestrojení vzorce, který po vložení hodnot vyprodukuje požadované výsledky měsíční splátky včetně celkového úroku. Implementace spotřebuje jen malou část úsilí potřebného pro vývoj softwaru a tento podíl navíc dlouhodobě klesá, zatímco nejvíce zdrojů se spotřebuje při provozu a údržbě. Programy se proto nevytvářejí tak, aby se lehce psaly, ale aby se lehce četly a modifikovaly. Při implementaci se dá postupovat dvěma základními způsoby. Při implementaci zdola-nahoru se nejdříve implementují části na nejnižších úrovních a ty se pak postupně spojují do větších celků. Základní výhodou tohoto přístupu je, že odladěné moduly nižších úrovní lze přímo 48\n56 použít při vytváření modulů vyšší úrovně. Mezi nevýhody pak patří to, že se chyby v logice projeví až v etapě integračního testování a že je systém možné předvádět až po jeho úplném dokončení. Při implementaci shora-dolů se nejdříve vytvoří moduly na nejvyšší úrovni a pak se postupně dokončují části na nižších úrovních. Výhodou tohoto přístupu je, že systém lze brzy demonstrovat a že nejzávažnější chyby jsou odhaleny včas. Nevýhodou je, že se logika systému ověřuje několikrát a že jsou pro testování potřeba speciální moduly, které simulují práce podsystémů. V praxi se používá kombinace obou přístupů. 22 Abychom dostali funkční kalkulátor úvěrů, je potřeba stanovit vzorec pro výpočet a ten převést do jazyka Java. Algoritmus Pro naše potřeby je nutné seznámit se s termínem anuita. Jedná se o splátku úvěru, která je v průběhu času stálá, čili nemění svojí výši. Anuita je složena z úroků a splátky jistiny. Poměr mezi těmito dvěma termíny je nejvyšší v počátcích splácení a s přibývajícím časem má tendenci klesat. Pro výpočet anuity se používá tento vzorec: Příklad S anuitní splátka U půjčená částka qn (q 1) S = U qn 1 q q = 1 + úroková míra za časovou jednotku n počet měsíců Od banky si půjčíme Kč s úrokem 3,15 % ročně na 60 měsíců. Jaká bude měsíční anuitní splátka? Nejprve je nutné rozpočítat úrokovou míru, tedy: Poté již jen dosadíme do vzorce: q = 1 + 0, = 1, , na šedesátou (1, ) S = , na šedesátou 1 22 KŘENA, PH.D., Ing. Bohuslav a Ing. Radek KOČÍ, PH.D. VUT FIT BRNO. Úvod do softwarového inženýrství: Studijní opora [online], s. 78. vyd. Brno, 2006 [cit ].\n57 Výsledek je: S = 3607,09 Kč [měsíčně] Nyní zbývá nabytý vzorec převést do podoby algoritmu, který bude schopen počítač a poté i systém Android bez problémů přečíst. Základní komponenty aplikace Aplikaci tvoří několik aktivit. Hlavní aktivitou je MainActivity, která po interakci s uživatelem provede výpočet anuity. Pomocná aktivita ListMesicu uživateli zobrazí seznam měsíců v rozmezí 12 až 240. Jde o výčtový seznam, který je zobrazován pomocí uživatelských prvků radiobutton. Tyto prvky zajistí, že nebudou uživatelem vybrány dvě a více hodnot. Pokud uživatel nevyplní požadované hodnoty, je zavolána toast notifikace, která uživatele upozorní na nevyplněné položky. Obrázek 21: Výčet měsíců s výběrem volby přes radiobutton [z vlastního zdroje] 50\n58 Hlavní část realizující výpočet představuje následující kus zdrojového kódu: Jedná se tedy o analogii vzorce, který je pouze převeden do jazyka Java. Hlavní pointou je získání měsíčního úroku úvěru. Roční úrokovou míru je tedy nutné vydělit číslem 12. Samotné tělo výpočtu pak představuje vztah, kde násobíme částku, kterou si chceme vypůjčit s měsíčním úrokem, a složeninou kde sčítáme měsíční úrok s číslem 1 a to celé umocníme počtem let splácení. Čitatel v tomto vzorci poté vydělíme hodnotou této složeniny. Velmi důležitý je XML soubor AndroidManifest, který specifikuje parametry aplikace Bankovního kalkulátoru. Zejména pak udělená oprávnění, tedy laicky řečeno, co aplikace může, na co smí sáhnout a co naopak nemůže. Naše aplikace kalkulátoru bankovních úvěrů má pouze jediný požadavek. A tím je přístup ke klávesnici uživatele, tedy jinými slovy řečeno odposlouchávání toho, co uživatel na klávesnici zadá. Součástí Manifestu je také specifikace minimální a maximální úrovně API. Toto rozmezí rozhoduje, na které verzi OS Android bude aplikace běžet optimálně a na které je možné očekávat nestandardní projevy, jako rozházené vizuální komponenty, nekompatibilita s daným zařízením, apod. Manifest může také obsahovat jeden anebo více elementů provider indikujících dodavatele obsahu, což jsou komponenty, které dodávají data vašim aktivitám a s vaším povolením také aktivitám jiných aplikací v zařízení. Dodavatele obsahu obalují databáze nebo jiné datové sklady do jediného API, které může používat jakákoliv aplikace. V Manifestu může být také obsažen element Service popisující služby, což jsou dlouhodobě spuštěné části zdrojového kódu, které mohou operovat nezávisle na jakékoliv aktivitě. Typickým příkladem služby je 51\n59 MP3 přehrávač, který má za úkol pokračovat v přehrávání, i když uživatel otevře jinou aktivitu, které uživatelské rozhraní přehrávače překryje. 23 Obrázek 22: Ukázka Manifestu aplikace Bankovní kalkulátor [z vlastního zdroje] Pokud bychom chtěli aplikaci distribuovat na Obchod Play/Play Store (dříve Android Market), je nutné vyplnit atribut minsdkversion, coby specifikaci úrovně, pro kterou bude aplikace plně optimalizována. Bankovní kalkulátor má nejnižší úroveň API levelu na čísle 9, která odpovídá verzi GingerBread (2.3). Verze Froyo a nižší tedy aplikací spustí, ale může docházet k již zmiňovaným nestandardním situacím. Cílený API level je nastaven na hodnotu 17, tedy v současnosti druhá nejrozšířenější verze Jelly Bean. Optimalizace pro nejnovější verzi Kit Kat proběhla prakticky automaticky, jelikož podložená funkčnost aplikace na verzi Jelly Bean se také přenáší do novějších verzí. 23 MURPHY, Mark L. Android 2: průvodce programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 31. ISBN\n60 Struktura projektu Bankovní kalkulátor Překladový systém OS Android je uspořádaný okolo specifické stromové struktury adresářů našeho projektu podobně, jako u jiných Java projektů. Specifika tohoto systému jsou však jedinečná. Nyní uvedu složení kořenového adresáře, který se vytvoří automaticky po implementaci nového projektu v prostředí Eclipse. Obsah kořenového adresáře Když vytvoříme nový Android projekt, vytvoří se také několik položek, které nalezneme v kořenovém adresáři projektu: AndroidManifest.xml: námi známý XML soubor popisující vyvíjenou aplikaci a komponenty, které aplikace obsahuje. Build.xml: Ant skript pro kompilaci aplikace a její instalaci na zařízení. Default.properties a local.properties: soubory nastavení, které používá překladový skript nástroje Ant. Assets/: složka obsahující ostatní statické soubory, které lze přibalit k aplikaci pro použití na zařízení. Bin/: složka, která uchovává aplikaci po jejím zkompilování. V této složce tedy nalezneme spustitelnou podobu aplikace, kterou poznáme pomocí přípony APK. Gen/: složka, do které překladové nástroje systému Android umístí zdrojový kód, který vygenerují. Příklad konfiguračního souboru: Libs/: složka uchovávající jakékoliv Java archivy třetích stran, které naše aplikace potřebuje. Src/: složka uchovávající zdrojový kód aplikace v jazyce Java. Res/: složka uchovávající prostředky, kterými mohou být ikony, návrhy GUI, apod. zabalené se zkompilovaným Java zdrojovým kódem aplikace. Tests/: složka, ve které je uložený úplně oddělený Android projekt, který lze použít pro testování námi vytvořeného projektu. 53\n61 Mezi nejobsáhlejší složku může v mnoha případech patřit složka res/, která obsahuje statické soubory, které se přibalí k naší aplikaci. Ve složce res/ nalezneme tyto adresáře: Res/drawable/: pro obrázky (PNG, JPEG, aj.) Res/layout/: pro specifikace uživatelského rozhraní založené na XML Res/menu/: pro specifikace menu založené na XML Res/raw/: pro obecné soubory (např. CSV soubory, aj.) Res/values/: pro řetězce, rozměry, apod. Res/xml/: pro další XML soubory, které bychom chtěli přibalit Testování Cílem testování je odhalit chyby během vývoje softwaru. Test, který neodhalí nesprávné chování systému, je neúspěšný. Na obrázku dále, vidíme typický proces testování systému. Nejdříve jsou navrženy testovací vstupy, což je v podstatě množina dvojic vstupní data/očekávaná výstupní data. Vstupní data jsou pak zadána programu na vstup, čímž získáme výsledky. Ty pak porovnáme s očekávanými výstupními daty a zjistíme, zda jsme odhalili chybu v programu. Chyba může být přitom výjimečně i v samotných testovacích vstupech. Celý proces testování vypadá na první pohled jednoduše. Jsou tu však dva zádrhely. Když výsledky neodpovídají očekávaným hodnotám (našli jsme tedy chybu), není vždy jednoduché najít ve zdrojových textech programu příčinu. Principiálně horším problémem však je výběr testovacích vstupů. Množina testovacích vstupů bývá příliš rozsáhlá, a proto můžeme vybrat jenom zlomek z nich. Testování proto nemůže prokázat, že v programu nejsou chyby, ale může pouze ukázat, že tam chyby jsou. 54\n62 Obrázek 23: Schéma testování SW projektů [převzato z google.com] Emulátor O několik stran dříve jsem se zmínil o emulátoru, který slouží jakožto dokonalá kopie operačního systému Android pro účely testování. Pokud bychom chtěli naše aktivity přeložit, je pro tyto účely emulátor dobrou volbou. I v případě, že nevlastníme nějaké Android zařízení. Emulátor se definuje v SDK Manageru, kde je nejdříve nutné projít si instalacemi požadovaných pluginů. Zejména tedy instrukčních sad, dokumentací, specifických sad pro spuštění emulátoru v prostředí desktopu a Google API pro námi požadovanou verzi systému Android. Po kompletní instalaci zvolíme v záložce Tools AVD Manager, ve kterém vytvoříme konečnou podobu emulátoru. 55\n63 Obrázek 24: Ukázka nastavení emulátoru [z vlastního zdroje] Při tvorbě emulátoru jen nutné brát na zřetel výkon počítače, na kterém jsme se rozhodli testovat. Pokud bychom chtěli emulovat tablet s vyšším rozlišením displeje, může se stát, že hardware našeho počítače bude takový emulátor vytvářet i několik desítek minut a samotný běh bude velmi ztížen četným zasekáváním. Ideální je vytvoření takového emulátoru, který kopíruje nejrozšířenější typy mobilních telefonů. Tedy 4 4,5 displej s rozlišením 800 x 480 bodů (maximálně 1280 x 768 bodů). Můžeme také zvolit již předpřipravené profily nejpoužívanějších telefonů. Na výběr je Nexus S, Nexus 4, Nexus 7, apod. Při tvorbě vlastního emulátoru volíme následující hodnoty: Name: volíme dle našeho výběru. Device: zde upřesníme velikost a rozlišení displeje. Target: jedná se o cílový operační systém, pro který bude aplikace plně optimalizována. CPU: zůstává defaultně na pozici architektury ARM Memory: volíme velikost operační paměti. Internal Storage: zde volíme velikost vnitřní paměti. 56\n64 SD Card: pokud hodnotu vyplníme, bude v emulátoru dostupná paměťová karta, na kterou můžeme instalovat aplikace. Obrázek 25: Ukázka nastavení virtuálního zařízení za účelem testování [z vlastního zdroje] Pokud jsme si nastavením jistí, zvolíme tlačítko Start. Výsledný emulátor je co do funkčnosti srovnatelný s mobilním telefonem obsahující OS Android. Na takto vzniklém emulátoru je možné bez problémů testovat již zkompilované APK balíky. Na níže uvedených obrázcích lze vidět perfektní funkčnost emulátoru s Androidem Jelly Bean: 57\n65 Obrázek 26: Ukázka zvirtualizovaného přístroje s OS Android [z vlastního zdroje] Uživatelské testování Velmi rozšířenou formou testování je uveřejnění beta verze, která je následně odzkoušená uživateli na různých typech přístrojů. Díky zpětné vazbě je možné výrazným způsobem odladit skryté chyby, či nevyhovující grafické znázornění aplikace. Ihned po vytvoření první beta verze jsem se rozhodl, že provedu menší průzkum na 30 uživatelích (22 mužů a 8 žen). Jednotliví účastníci průzkumu obdrželi soubor APK, který si nainstalovali na svoje přístroje s různými verzemi OS Android. Poté aplikaci řádně vyzkoušeli. Výstupem bylo zodpovězení pěti otázek, jejichž výsledky znázorňuji do následujících grafů. 1. Otázka první Myslíte si, že je aplikace natolik užitečná, že byste si jí zdarma stáhli z obchodu Play? 58\n66 Užitečnost aplikace při stažení zdarma 22% 78% Ano Ne 2. Otázka druhá - Myslíte si, že je aplikace natolik užitečná, že byste si jí za symbolický poplatek 20 Kč stáhli z obchodu Play? Užitečnost aplikace při stažení za poplatek 42% 58% Ano Ne 3. Otázka třetí Jak hodnotíte design a provedení aplikace? 59\n67 Líbí se Vám design aplikace? 38% 62% Líbí Nelíbí 4. Otázka čtvrtá Vlastníte některý z úvěrových produktů? Vlastníte úvěr? 24% 76% Ano Ne 5. Otázka pátá Byla by pro Vás tato aplikace výrazným pomocníkem při sjednávání úvěru na pobočce? 60\nBankovní institut vysoká škola Praha Katedra informatiky a kvalitativních metod Vývoj mobilních aplikací Diplomová práce Autor: Bc. Tomáš Hochmuth Informační technologie a management Vedoucí práce: Ing.\nVývoj OS Windows Mobile. Ing. Jiří Šilhán\nVývoj OS Windows Mobile Ing. Jiří Šilhán Počátky vývoje Windows Mobile (též označovaný jako Windows CE) začíná roku 1992. Hlavním cílem bylo vyvinout mobilní zařízení s operačním systémem Windows. Myšlenkou


Fidelity: Paradox hospodářské politiky | Warengo\n07.12.2021 • 5 minut čtení\nJedním z dilemat je, jak zpřísnit měnovou politiku a zkrotit inflaci, aniž by se utlumilo hospodářské oživení. Dalším, jak se vyrovnat s vyššími cenami energií v době, kdy svět přechází na nízkouhlíkovou ekonomiku.\nRok 2021 přinesl oživení, ve které mnozí doufali. Firmy se znovu otevřely, dojíždějící se vrátili ke svým pracovním stolům a ti nejodvážnější z nás dokonce vyrazili na dovolenou. Situaci však nelze označit za „návrat k normálu“ vzhledem k raketově rostoucím cenám energií, vysoké úrovni zadlužení a růstu, který se již nachází za vrcholem.\nTyto podmínky zvyšují riziko měnově politické chyby v příštích 12 měsících. Centrální banky a vlády totiž snaží zorientovat v radách typu „Hlava XXII“ nebo Hlava 2022 (připomínající hlavolamy, jakým čelí posádka letadla v románu Josepha Hellera z roku 1961), aniž by ztratily důvěru trhů.\nJedním z dilemat je, jak zpřísnit měnovou politiku a zkrotit inflaci, aniž by se utlumilo hospodářské oživení. Dalším, jak se vyrovnat s vyššími cenami energií v době, kdy svět přechází na nízkouhlíkovou ekonomiku. Vyladit nastavení hospodářské politiky tak, aby tyto protichůdné vlivy vyvážila, nebude snadné.\n„Navzdory rétorice centrálních bank o přechodnosti inflačních tlaků se zdá, že cenový růst bude v některých případech přetrvávat v důsledku zablokování dodavatelských řetězců a omezení globalizace,“ vysvětluje Andrew McCaffery, globální CIO pro správu aktiv Fidelity International. V dlouhodobějším horizontu také kvůli nákladům na dosažení uhlíkové neutrality. Nechat roztočit inflační spirálu by způsobilo jen větší problémy, ale agresivní potlačení inflace by mohlo dál brzdit růst, k jehož pozastavení mezitím již došlo.\n„Celkově očekáváme, že úrokové sazby zůstanou nižší po delší dobu, navzdory vyšším cenám a snaze centrálních bank relativně rychle omezit nákupy aktiv. Ultra nízké sazby jsou nutné k udržení systému nad vodou vzhledem k tomu, že úroveň zadlužení je dnes vyšší než za druhé světové války,“ dodává Andrew McCaffery.\nZAMĚŘENÍ ČÍNY NA REÁLNOU EKONOMIKU\nČína se mezitím zdá být odhodlaná přejít na ekonomický model zaměřený na reálnou ekonomiku, snižuje zadlužení a řeší systémové nerovnováhy, než aby reagovala na případné zhoršení finanční situace aktiv. To by mělo pomoci trhům z dlouhodobého hlediska, což zvýší morální hazard a umožní investorům přesněji oceňovat aktiva. Politický postoj země by však mohl negativně ovlivnit globální růst v roce 2022 a konsenzuální očekávání by mohla být revidována směrem dolů.\nVLIV KLIMATU NA ALOKACI AKTIV\nPotřeba přemýšlet o dopadu klimatických faktorů na alokaci aktiv se v roce 2021 zvýšila a v roce 2022 dál vzroste. Dovozci fosilních paliv si přejí zlepšit energetickou bezpečnost, zatímco investoři preferují klimatická řešení a nové technologie v rámci příprav na radikálnější změnu orientace ekonomiky. Vlády jednotlivých zemí přiznávají klimatické změně vysokou prioritu a klimatické politiky jsou čím dál častější, ačkoli to samé nelze říci na globální úrovni.\nZcela zvlášť stojí výzva změny spotřebních vzorců. Na cestě za uhlíkovou neutralitou ještě očekáváme řadu dalších překážek, z nichž některé nebyly adekvátně promítnuty v cenách. Vzhledem k potenciálnímu zvýšení korelace mezi veřejně obchodovanými cennými papíry v roce 2022 se domníváme, že soukromé trhy by mohly i nadále nabízet alternativní růstové profily pro dlouhodobé investory, zejména v oblasti ekologizace hnědých aktiv. Vybrané asijské dluhopisy a akcie by měly posloužit jako diverzifikace, zatímco (hodnotově orientované) části rozvinutých akciových trhů a nemovitostí mohou poskytnout zajištění proti mírné inflaci.\nDYNAMIKA AMERICKÉHO DOLARU\nProstředí kolem amerického dolaru se mění s tím, jak se země více spoléhá na spřátelené protistrany při nákupu svého dluhu. V roce 2022 může měna těžit z defenzivnějšího postoje, pokud se zvýší volatilita. Pokud však Čína a Japonsko urychlí uvolňování svých expozic a/nebo se posunou výše na výnosové křivce, znepokojeni debatami o dluhovém stropu, fiskálním deficitem USA a vysokou úrovní peněžní zásoby, pak v určitém okamžiku bude možná Fed muset nabídnout vyšší výnosy, aby přilákal domácí kupce.\nZároveň se v roce 2022 sníží fiskální podpora, což by mohlo způsobit, že příjmy budou napjaté a nezaměstnanost stoupne, zejména pokud ceny energií zůstanou vysoké. Centrální banky mohou zjistit, že najednou nemají jinou možnost než ustoupit od své rétoriky o utahování likvidity. Pokud se nestáhnou, může přijít na řadu „háček“. Trhy mohou uvěřit, že s námi inflace zůstane mnohem déle, což povede k dalšímu přecenění rizika v průběhu roku.\nBitcoin a monetární politika\nBurzovní kalendář 28/52 - Co musíme vědět do nového týdne!\nBurzovní kalendář 51/52 - Co musíme vědět do nového týdne!\nBurzovní kalendář 50/52 - Co musíme vědět do nového týdne!\nClosing Bell (15. 6. 2021) – S&P 500 navyšuje maxima, čeká se na zítřejší výstup ze zasedání FEDu\nRok 2021 - jasnější příležitosti, nebo spousta rizik?