Vývoj mobilních aplikací

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:

Praha

Ing. Jan Háněl

Duben, 2014

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

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.

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 on the development of mobile applications deals with an extensive issue which consists of the design and optimization of 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 Google Android operating system. The work covers all the pitfalls and dangers of development for mobile devices and through practical output it can act as a guide for beginning developers. Rich theoretical basis will guide the reader through all the differences in development for various operating systems and will also provide a good quality summary of information which a beginning developer might find useful.

KEYWORDS Application Development, Android, Bank calculator, smart phones, tablets

Obsah Obsah ...................................................................................................................................................... 5 1.

2.

Úvod ................................................................................................................................................ 1 1.1.

Cíl práce ................................................................................................................................... 2

1.2.

Historie mobilních platforem .................................................................................................. 3

1.3.

Google Android ....................................................................................................................... 4

1.4.

Apple iOS ................................................................................................................................. 6

1.5.

Windows Phone ...................................................................................................................... 8

Úvod do vývoje mobilních aplikací ................................................................................................ 10 2.1.

Architektura OS Android ....................................................................................................... 11

2.1.1. 2.2.

Členění vrstev architektury OS Android ........................................................................ 12

Přístup k vývoji multiplatformního řešení ............................................................................. 14

2.2.1.

Nativní aplikace ............................................................................................................. 14

2.2.2.

Webové aplikace ........................................................................................................... 14

2.2.3.

Hybridní aplikace ........................................................................................................... 14

2.3.

Anatomie aplikací pro OS Android ........................................................................................ 15

2.3.1.

Notifikace (oznámení) ................................................................................................... 16

2.3.2.

Toast oznámení ............................................................................................................. 16

2.3.3.

Oznámení ve stavovém řádku ....................................................................................... 17

2.3.4.

Oznámení formou dialogového okna ............................................................................ 17

2.4.

Životní cyklus aplikace ........................................................................................................... 18

2.5.

Životní cyklus aktivity ............................................................................................................ 18

2.6.

Vlákna a procesy.................................................................................................................... 21

2.6.1.

Priorita procesů ............................................................................................................. 21

2.6.2.

Vlákna ............................................................................................................................ 22

2.7.

Android Manifest .................................................................................................................. 23

2.7.1.

Elementy........................................................................................................................ 23

2.7.2.

Atributy.......................................................................................................................... 24

2.7.3.

Přístupová oprávnění .................................................................................................... 24

2.7.4.

Knihovny ........................................................................................................................ 24

2.7.5.

Úrovně API (API Level) ................................................................................................... 24

2.8.

Nástroje pro vývoj aplikací v operačním systému Android ................................................... 26

2.8.1.

Eclipse ............................................................................................................................ 26

2.8.2.

Android SDK................................................................................................................... 26

2.8.3.

Android ADB .................................................................................................................. 27

2.8.4.

Fastboot......................................................................................................................... 27

2.8.5.

Android NDK .................................................................................................................. 27

2.8.6.

HyperNext Android Creator .......................................................................................... 28

2.8.7.

IntelliJ IDEA .................................................................................................................... 28

2.8.8.

PhoneGAP...................................................................................................................... 28

2.8.9.

Oracle ADF Mobile ........................................................................................................ 29

2.9.

Uživatelské rozhraní OS Android ........................................................................................... 30

2.9.1.

Rozvržení obrazovky ...................................................................................................... 31

2.9.2.

Rotace obrazovky při změně polohy zařízení ................................................................ 31

2.10.

3.

Vizuální komponenty systému Android ............................................................................ 33

2.10.1.

Textové popisky............................................................................................................. 33

2.10.2.

Tlačítka .......................................................................................................................... 33

2.10.3.

Zaškrtávací tlačítka ........................................................................................................ 34

2.10.4.

Přepínače....................................................................................................................... 35

2.10.5.

Obrázky.......................................................................................................................... 36

Ekonomická základna aplikace ...................................................................................................... 37 3.1.

Úvěr ....................................................................................................................................... 37

3.2.

Úroková míra ......................................................................................................................... 38

3.3.

RPSN ...................................................................................................................................... 38

3.3.1. 4.

Úvod do praktické části práce ....................................................................................................... 40 4.1.

Java Development Kit (JDK) ................................................................................................... 40

4.2.

Software Development Kit (SDK) .......................................................................................... 40

4.2.1.

Základní konfigurace SDK: ............................................................................................. 41

4.2.2.

Doporučená konfigurace SDK:....................................................................................... 41

4.2.3.

Plné konfigurace SDK: ................................................................................................... 41

4.3.

Optimalizace vývojového prostředí Eclipse .......................................................................... 42

4.4.

Struktura projektu Bankovní kalkulátor ................................................................................ 44

4.4.1. 5.

Výpočet RPSN ................................................................................................................ 38

Obsah kořenového adresáře ......................................................................................... 44

Tvorba aplikací pro mobilní zařízení.............................................................................................. 46 5.1.

Etapy životního cyklu softwaru ............................................................................................. 46

5.2.

Analýza a návrh projektu Bankovní kalkulátor...................................................................... 48

5.2.1.

Definice vizuálního stylu................................................................................................ 49

5.2.2. 5.3.

Implementace ....................................................................................................................... 52

5.4.

Objektově orientovaný návrh implementace ....................................................................... 53

5.5.

Implementace databáze ........................................................................................................ 56

5.5.1. 5.6.

Získání dat o produktech z databáze ............................................................................. 57

Testování ............................................................................................................................... 58

5.6.1.

Testování během vývoje................................................................................................ 58

5.6.2.

Emulátor ........................................................................................................................ 59

5.6.3.

Fyzické testování ........................................................................................................... 62

5.7. 6.

Základní layout aplikace ................................................................................................ 50

Ovládání aplikace Bankovní kalkulátor ................................................................................. 63

Distribuce aplikací prostřednictvím Obchodu Play ....................................................................... 69 6.1.

Registrace do Google Play ..................................................................................................... 70

6.2.

Postup pro vložení aplikace na Google Play .......................................................................... 70

7.

Závěr .............................................................................................................................................. 74

9.

Seznam použité literatury ............................................................................................................. 75 9.1.

Tištěné monografie ............................................................................................................... 75

9.2.

Elektronické monografie ....................................................................................................... 76

1. Úvod 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

modelů mobilních telefonů. A právě tomuto mladému operačnímu systému se bude tato diplomová práce věnovat.

1.1.

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í. 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

1.2.

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 1998“1. Pravý operační systém v té podobě, ve které ho většina z nás zná, přišel kolem roku 2001. 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

1

Symbian OS. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 20012014 [cit. 2014-04-20+. Dostupné z: http://cs.wikipedia.org/wiki/Symbian_OS

3

inspirovalo rostoucím Androidem. Ať byl Symbian jakkoliv průlomovým systémem, 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.

1.3.

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 2.6.25. 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 4

všechny vývojové větve Androidu vždy open-source. Android ve verzi 3.0 a jeho inovované 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ě 9. 7. 2012, 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.

5

Příloha č. 1

GIZMODO.CO.UK: Android Evolution [fotografie]. Dostupné z: http://media.gizmodo.co.uk/wpcontent/uploads/2012/12/AndroidEvolution.jpg.

1.4.

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 6

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 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.

7

1.5.

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řejmenované 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 2012. 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 8

rozhodl vydávat objemné systémové aktualizace, které měly po vzoru konkurence, přidávat 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.

9

2. Ú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ícími 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

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á.

2.1.

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

„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 Příloha č. 2

ELINUX.ORG: Android Architecture [fotografie]. Dostupné z: http://elinux.org/images/c/c2/Android-systemarchitecture.jpg.

2.1.1. Členění vrstev architektury OS Android 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.

2

UJBÁNYAI, Miroslav. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012, s. 17. Průvodce (Grada). ISBN 978-80-247-3995-3.

12



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



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.

3


13



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.



Package Manager – sestává z informací o aplikacích nahraných do OS Android.

Applications Poslední vrstvou jsou již samotné aplikace, které většina uživatelů vnímá coby ikonky v Obchodu Play. Tyto aplikace mohou být v samotném systému také předinstalovány.

2.2.

Přístup k vývoji multiplatformního řešení

Vývojář, který vytváří mobilní aplikace, může čerpat z ohromného množství postupů, jak docílit vytvoření aplikace pro danou platformu. Z hlediska členění se aplikace dělí do třech základních typů:

2.2.1. Nativní aplikace Nativní aplikace je postavena přesně na daný typ operačního systému. Je tedy vyvíjena pod specifickým programovacím jazykem a pracuje přímo s operačním systémem mobilního zařízení. Vzhledem k tomu, že je tato spolupráce velmi těsná, jsou tyto aplikace z hlediska výkonu nejrychlejší a samozřejmě také nejstabilnější. Do této skupiny můžeme zařadit graficky náročné hry, aplikace obsluhující fotoaparát, apod. Jako příklad nativní aplikace lze uvést Angry Birds či Facebook.

2.2.2. Webové aplikace Základním rozlišovacím pravidlem je skutečnost, že k běhu aplikace je nutný webový prohlížeč. Aplikace tedy běží přímo v něm. Tvoříme jí nejčastěji pomocí HTML5, CSS a JavaScriptu. Z hlediska výkonu se jedná o značně jednoduché aplikace, nejčastěji na bázi vyhledávacích služeb – jízdní řády, hudba, filmy, apod. Mezi hlavní negativum patří neschopnost pracovat bez internetového připojení.

2.2.3. Hybridní aplikace Poslední typ aplikací je velmi podobný té nativní s tím rozdílem, že jádro aplikace je tvořeno pomocí standardních webových technologií, jako je HTML+CSS či JavaScript. Toto webové jádro je uloženo a spuštěno uvnitř nativní aplikace. Dokončení aplikace je postaveno na stejných nástrojích, jako u nativních aplikací.

14

Příloha č. 3

BLOG.MELTMEDIA.COM: There´s More Than One Way to Build Mobile Apps [fotografie]. Dostupné z: http://blog.meltmedia.com/wp-content/uploads/2013/05/Mobile-App-Tech-Stacks.png.

2.3.

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ší

4

MURPHY, Mark L. Android 2: průvodce programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 23. ISBN 978-80-251-3194-7.

15

představu lze záměru nadefinovat určitě postupy událostí, které budou reagovat 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 %. 2.3.1. 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:

2.3.2. 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 emailu, či SMS.

16

Příloha č. 4

BANKOVNÍ KALKULÁTOR: Ukázka toast upozornění [fotografie].

2.3.3. 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í.

2.3.4. 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

5


17

2.4.

Ž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 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é.

2.5.

Ž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

6

KRYPTA, Tomáš. Vyvíjíme pro Android – tvoříme aktivity. In: KOSEK, Jiří. *online+. 2011 *cit. 2014-04-20]. Dostupné z: http://www.abclinuxu.cz/clanky/vyvijime-pro-android-tvorime-aktivity

18

Příloha č. 5

ZDROJÁK.CZ: Vyvíjíme pro Android: Dialogy a aktivity [fotografie]. Dostupné z: http://www.zdrojak.cz/wpcontent/uploads/static/2012/08/activity-lifecycle-1-prev.png.

„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 ukončení jejího procesu, je potřeba si stav aktivity uložit, jelikož v paměti procesoru se po ukončení aplikace její stav již nenachází. Pokud tak 19

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


20

2.6.

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.

2.6.1. 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. 21

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í.

2.6.2. 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.

22

2.7.

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 Příloha č. 6

BANKOVNÍ KALKULÁTOR: Ukázka manifest souboru [fotografie]

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

2.7.1. Elementy Elementy <manifest> a 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.

23

2.7.2. Atributy Opět platí tvrzení, že určité atributy jsou povinné a jejich neuvedení by znamenalo nefunkčnost aplikace.

2.7.3. 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

2.7.4. 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.

2.7.5. Ú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 8


24

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 Android. Nejnovější verze systému Android – Kit Kat má API úroveň 19. Aplikace s deklarovaným API Level 17 bude plně kompatibilní i se starší verzí, tedy např. Ice Cream Sandwich, Gingerbread, či Froyo, apod. Příloha č. 7

DEVELOPER.ANDROID.COM: What is API Level? [tabulka]. Dostupné z: http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

25

2.8.

Nástroje pro vývoj aplikací 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.

2.8.1. 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

2.8.2. 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 9

Eclipse - The Eclipse Foundation open source community website. [online]. [cit. 2014-04-20+. Dostupné z: https://www.eclipse.org/

26

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. 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.

2.8.3. 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.

2.8.4. 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.

2.8.5. 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. 27

2.8.6. HyperNext Android Creator Jedná se o ekvivalent vývojového prostředí, určeného pro začínající programátory, kterým je umožněno vytvářet své vlastní aplikace bez znalosti jazyka Java a Android SDK. Toto prostředí je založeno na tzv. Hyper kartách, které pracují na principu viditelnosti jedné karty v každém okamžiku. Využití v mobilních telefonech, které mají viditelné vždy jen jedno okno, je tedy nasnadě. Hlavní programovací jazyk se nazývá HyperTalk. Jedná se o procedurální programovací jazyk původně vytvořený primárně pro Apple. Jazyk je velmi podobný psané angličtině a používá podobnou logickou strukturu jako programovací jazyk Pascal.

2.8.7. IntelliJ IDEA V poslední době toto komerční vývojové prostředí překonává zažitý open-source Eclipse IDE. Zajímavý je zejména ve své poslední verzi 10, která zahrnuje podporu platformy Android. Vývojové prostředí IntelliJ IDEA je velmi jednoduché a v porovnání s Eclipse není tak mohutné a tudíž méně náročné pro hardware počítače. Velkou výhodou tohoto vývojového nástroje může být bezchybná kompatibilita s Eclipse, podpora diagramů tříd UML, či detekce duplicit v kódu. IntelliJ IDEA je možné používat zdarma, pro komerční použití je pak nutné zakoupit verzi Ultimate. Nutno dodat, že mezi českými vývojáři jde o stále více upřednostňované řešení, před IDE Eclipse.

2.8.8. PhoneGAP V poslední době se jedná o velmi populární nástroj pro tvorbu mobilních aplikaci napříč všemi platformami. Opět jej můžeme zařadit do sekce vývojářům – začátečníkům, přesto je nutné podotknout, že se v žádném případě nejedná o nástroj, ve kterém by byly aplikace polo funkční, či s kompromisy. K plnému využití stačí znát základy HTML (příp. HTML5 + CCS3) a JavaScriptu. Samotný Framework, koupený společností Adobe se pak postará o převod do hybridní podoby – nejedná se o plně nativní aplikace, protože layout je vykreslován přes webové rozhraní, ovšem není to ani čistě webová záležitost, jelikož je výstupem spustitelný balík pro danou distribuci včetně přístupu k nativnímu API. Jádro PhoneGap aplikace je nejčastěji HTML5 a CSS3 pro vykreslené a JavaScript pro logickou část. Ačkoliv nyní HTML5 poskytuje přístup k hardwaru, jako je fotoaparát či GPS, není jeho využití zejména na starších verzích Androidu konzistentní. Využití této webové technologie je v každém případě vždy pomalejší, než nativní podoba s podobnou funkčností. V případě Applu se tedy často stává, že jsou aplikace odmítnuté přímo AppStorem pro nedostatečnou optimalizaci s důrazem na rychlost či s neobvyklým grafickým vzhledem aplikace. PhoneGap 28

podporuje většinu dnešních mobilních platforem, zejména tedy Android, iOS, Windows Phone, ale také Symbian, Tizen či BlackBerry. Příloha č. 8

MATTEOMAGNI.NET: Presentation PhoneGAP course: PhoneGAP Architecture [fotografie]. Dostupné z: http://matteomagni.net/presentation-phonegap-course/images/phonegap-architecture.jpg

2.8.9. 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í.

29

Příloha č. 9

TECHNOLOGY.AMIS.NL: The year of the ADF developer @ Oracle Open World [fotografie]. Dostupné z: http://technology.amis.nl/wp-content/uploads/images/adfmobile-architecture.jpg

2.9.

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ž

30

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

2.9.1. 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í: 

„Relativní rozvržení – v tomto typu lze nadefinovat umístění objektů relativně vůči obrazovce, nebo jiným objektům.



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.



Tabulkové rozvržení – umožňuje rozložit objekty pomocí mřížky řádků a sloupců.



Absolutní rozvržení – je definováno pomocí absolutních souřadnic, které zaručí přesné rozložení komponent.“11

2.9.2. 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. 72-73. Průvodce (Grada). ISBN 978-80-247-3995-3.

31

„Chování

rozvržení,

v rámci

změny

android:screenOrientation

orientace

náležícího

lze

v souboru

definovat

pomocí

atributu

AndroidManifest.xml

elementu . 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í.“ 12

12

UJBÁNYAI, Miroslav. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012, 187 s. Průvodce (Grada). ISBN 978-80-247-3995-3.

32

2.10.

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í.

2.10.1.

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

2.10.2.

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


33

Použití tlačítka na návrhovém plátně spolu s deklarací v XML můžeme vidět na tomto obrázku: Příloha č. 10

BANKOVNÍ KALKULÁTOR: Ukázka deklarace tlačítka [fotografie].

2.10.3.

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 Javě 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é (vrací hodnotu boolean)



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:

34

Příloha č. 11

BANKOVNÍ KALKULÁTOR: Ukázka deklarace zaškrtávacího tlačítka [fotografie].

2.10.4.

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.

35

Příloha č. 12

BANKOVNÍ KALKULÁTOR: Ukázka deklarace přepínače [fotografie].

2.10.5.

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: 

res/drawable-hdpi/



res/drawable-mdpi/



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


36

Příloha č. 13

BANKOVNÍ KALKULÁTOR: Rozdíl mezi obyčejným obrázek a tzv. akčním obrázkem, který po kliknutí provede určitou akci [fotografie].

3. Ekonomická základna aplikace Abychom byli schopni porozumět funkčnosti aplikace, je nutné si ozřejmit základní terminologii z hlediska ekonomie. Bankovní kalkulátor coby sumář bankovních úvěrů na trhu, obsahuje několik specifických vzorců, díky kterým dokáže vypočíst jednotlivé prvky úvěru, jako RPSN (roční procentuální sazbu nákladů), měsíční splátku aj.

3.1.

Úvěr

Úvěrem rozumíme dočasné zapůjčení finančního obnosu za úplatu. Tento obnos je nutné splatit do určitého časového horizontu a jedinec, který takový obnos zapůjčí, očekává jisté zhodnocení této sumy. Nejčastěji ve formě „výpůjčného“. U bankovních úvěrů (nabízí je bankovní ústavy) je toto zhodnocení formou úrokové míry a často také (nepřímo) různými poplatky, ze kterých ústav zhodnocuje své podnikání.

37

3.2.

Úroková míra

Jedná se o procentuální vyjádření zvýšení vypůjčené částky za určitý časový úsek. Zjednodušeně nám tato míra poukazuje na fakt, kolik daný úvěr bude konečného dlužníka stát.

3.3.

RPSN

Prostřednictvím roční procentní sazby nákladů si lze ověřit výhodnost daného finančního produktu. Nejčastěji se prezentuje v porovnání s ostatními finančními ústavy. Úrok poukazuje na cenu zapůjčení peněz, RPSN v sobě zahrnuje náklady s finančním produktem, tedy: 

Poplatky za uzavření a vedení úvěrového účtu



Poplatky vztahující se k převodu peněz



Akontace = první navýšená splátka



Pojištění schopnosti splácet, aj.

3.3.1. Výpočet RPSN „RPSN vyjadřuje úrokovou míru, pro kterou se rovná čistá současná hodnota získaných půjček čisté současné hodnotě výdajů (splátek, poplatků apod.), jedná se tedy o takové r, pro které platí následující rovnice:

,

Kde: m je počet poskytnutých půjček, Ai je výše i-té poskytnuté půjčky, ti je doba (v letech a zlomcích roku ode dne 1. půjčky), kdy byla i-tá půjčka poskytnuta, n je počet plateb, Bj je výše j-té platby (splátky, poplatku atd.), sj doba (v letech a zlomcích roku ode dne 1. půjčky), kdy byl j-tý poplatek zaplacen.“15 Měsíční splátka úvěru

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

15

RPSN. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014 [cit. 2014-04-20+. Dostupné z: http://cs.wikipedia.org/wiki/RPSN

38

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: (

)



S – anuitní splátka



U – půjčená částka



q – q = 1 + úroková míra za časovou jednotku



n – počet měsíců

Příklad

Od banky si půjčíme 200 000 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: (

)

Výsledek je:

Tento výpočet je poté nutno převést do algoritmické podoby jazyka Java, pomocí které aplikace vypočítá výslednou měsíční anuitní splátku.

39

4. Ú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 splatné bance. Aplikace navíc poskytne jedinečný přehled všech bankovních produktů na trhu, jejich vzájemné srovnání a také případně třídění dle výhodnosti. 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.

4.1.

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.

4.2.

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.

40

4.2.1. 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.

4.2.2. 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.

4.2.3. 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.

41

Příloha č. 14

BANKOVNÍ KALKULÁTOR: SDK Manager sloužící k výběru instalovaného API, pro které chceme vyvíjet [fotografie].

4.3.

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ů.“ 16

16


42

Příloha č. 15

BANKOVNÍ KALKULÁTOR: Deklarace API úrovně včetně patřičného SDK [fotografie].

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.“ 17

17


43

Příloha č. 16

BANKOVNÍ KALKULÁTOR: Rozvržení vývojového prostředí Eclipse [fotografie].

Struktura projektu Bankovní kalkulátor

4.4.

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.

4.4.1. 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. 44



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.

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

45

5. Tvorba aplikací pro mobilní zařízení 5.1.

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.“18 „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é.

18

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. 2014-04-21].

46

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í.“19

19


47

5.2.

Analýza a návrh projektu Bankovní kalkulátor

Cílem projektu je vytvořit kalkulátor bankovních úvěrových produktů. Aplikace po zadání atributů poskytne sumář výsledků všech bankovních ústavů, které pro zadaná kritéria nabízejí vhodný úvěrový produkt. Součástí tohoto výpisu bude informace o výši RPSN, či případných poplatků za správu úvěru, případně sankce za předčasné splacení. Pro bezproblémové provedení algoritmů je nutné zadat tyto údaje:   

Výše úvěru – uvedení částky v celých číslech (např. 200 000 Kč) Doba splácení v měsících – výběr z přednastavených hodnot (např. 60 měsíců, maximum je 240) Řazení výsledků – na výběr jsou dvě hodnoty. Řazení dle měsíčních splátek a celkové splatné částky bance.

Aplikace po zadání všech potřebných atributů zavolá napevno dané hodnoty z databáze, která obsahuje všechna potřebná data, jako např. úrokovou míru, sankce za předčasné splacení úvěru, RPSN, apod. V případě aktualizace podmínek bankovních produktů (změna úrokové sazby, atp.) bude vydán aktualizační balíček formou updatu přes Obchod Play. Aplikace tak bude vždy aktuální. Po rozkliknutí jednotlivých nabídek se uživateli zobrazí pop-up okno s informací o výši RPSN a sankcí za předčasné splacení úvěru. Ekvivalentem této aplikace je internetový srovnávač úvěrů na webové adrese http://www.mesec.cz/produkty/spotrebitelskeuvery/. Design kalkulátoru 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é.

48

Příloha č. 17

BANKOVNÍ KALKULÁTOR: Ukázka pop-up okna s informacemi o výši RPSN a sankcí za předčasnou splátku [fotografie].

5.2.1. Definice vizuálního stylu 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í jsem došel k závěru, že standardní HOLO design nahradíme graficky příjemnějším layoutem, jehož srovnání lze nalézt na níže uvedeném obrázku.

49

Příloha č. 18

BANKOVNÍ KALKULÁTOR: Rozdíl mezi základním a customizovaným designem [fotografie]

5.2.2. 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 HLEDAT 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.



Tabulkový layout – tento typ rozvržení si lze představit jako tabulku obsahující řádky a sloupce. 50



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 – nová obrazovka, kde se zobrazují výsledky. Tento výpis sestává z horní notifikační lišty, která poskytuje informace o počtu nabídek na zadané parametry. Hodnoty se budou měnit v závislosti na výši zadaného úvěru (některé finanční ústavy nepůjčují méně, než 5.000 Kč., apod.). V další části je již samotný výpis nabídek řazený v základu dle nejvýhodnější nabídky.

51

Příloha č. 19

BANKOVNÍ KALKULÁTOR: Ukázka výsledkové části aplikace [fotografie].

5.3.

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 52

celků. 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 praxi se používá kombinace obou přístupů.“20

5.4.

Objektově orientovaný návrh implementace

Aplikace obsahuje jeden implementační balíček cz.app.calculator, který obsahuje několik tříd. Nejdůležitějšími třídami z hlediska uživatelského rozhraní jsou třídy MainActivity a ListIemActivity, které plní daty obrazovky aplikace. Pro komunikaci s databází slouží třída MySQLHelper, pomocí které jsou získávána data o jednotlivých produktech. Tyto produkty jsou reprezentovány jako objekty třídy CustomerCredit. Na rozdíl od databázové tabulky customer_credit objekty obsahují také další položky, jejichž výpočet je zajištěn ve třídě CustomerCreditDataSource. Mezi tyto položky patří výpočet měsíčních splátek monthPayment, výpočet celkové částky splatné bance bankAmount, ale také vypočtená RPSN, kterou reprezentuje položka apr. Výpočet RPSN je zajištěn ve třídě APR. Poslední třídou použitou při implementace aplikace je třída CustomerCreditListAdapter, která zajišťuje správné přiřazení hodnot do výpisu položek k jednotlivým produktům. Příloha č. 20

BANKOVNÍ KALKULÁTOR: Objekt CustomerCredit reprezentující produkty jednotlivých bank [fotografie].

Část, ve které probíhá výpočet měsíční splátky, můžeme demonstrovat na následujícím kusu zdrojového kódu:

20


53

Příloha č. 21

BANKOVNÍ KALKULÁTOR: Výpočet měsíční splátky [fotografie].

Jedná se o analogii vzorce, který je pouze převeden do jazyka Java. Hlavní pointou je následující vzorec: Denní úrok = minimální úroková sazba úvěru / 1200 Index = 1 / (1 + denní úrok) Měsíční splátka = výše úvěru * denní úrok / (1 – index počet měsíců)

Výpočet celkové částky zaplacené bance: Částka = měsíční splátky * počet měsíců + roční poplatek za správu * počet měsíců / 12

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é

54

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 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.“21 Příloha č. 22

BANKOVNÍ KALKULÁTOR: Ukázka manifestu aplikace [fotografie].

21


55

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í.

5.5.

Implementace databáze

Návrh datových struktur obsahuje celkem dvě databázové tabulky. První tabulka bank obsahuje mimo primárního klíče pouze název finančního ústavu, tedy banky. Druhá tabulka customer_credit obsahuje produkty daných bank, díky kterým je možné poskytnout žadateli osobní úvěr. Provázanost tabulek zajišťuje cizí klíč bid v tabulce customer_credit. Protože může jedna banka poskytovat více produktů, jsou tyto tabulky ve vztahu 1:N. Pro potřeby aplikace je důležité, aby byly ke každému produktu zaznamenány všechny potřebné informace. Sloupec product_name datového typu TEXT obsahuje název produktu, min_rate_loan typu FLOAT zaznamenává minimální úrokovou sazbu úvěru. Roční poplatek za správu úvěru reprezentuje sloupec management_fee_year typu INTEGER a minimální možnou výši poskytnutého úvěru sloupec min_loan_amount typu INTEGER. Nechybí ani poplatky spojené s úvěrem ve sloupci loan_fees typu INTEGER a poplatky za předčasné splacení úvěru ve sloupci penalties. Tyto poplatky jsou popsány textově, a proto je sloupec typu TEXT. Příloha č. 23

BANKOVNÍ KALKULÁTOR: Grafické vyjádření SQL databáze [fotografie].

56

5.5.1. Získání dat o produktech z databáze Data z tabulek získáváme následujícím příkazem: SELECT * FROM customer_credit JOIN bank ON customer_credit.bid = bank.bid; Ukázku zdrojového kódu poskytuji níže: Příloha č. 24

BANKOVNÍ KALKULÁTOR: Ukázka části kódu reprezentující funkcionalitu databáze [fotografie].

Zdrojový kód pokračuje částí, ve které se praktikuje naplnění tabulky daty o názvech bank, poté přecházíme do části, kde již jednotlivě plníme třiadvacet záznamů pevnými parametry.

57

Parametry jsou název bankovního produktu, úroková míra, rozmezí částky, na které se daný produkt vztahuje a informace o sankci za předčasnou splátku.

5.6.

Testování

Testování je nepochybně nejdůležitější částí vývoje SW produktů. Je nutné mu věnovat dostatek času a předem si promyslet postupy, které budeme u testování praktikovat. U testování mobilních aplikací se bavíme o několika postupech, které v konečném důsledku mohou odhalit i faktické chyby, které jsme přehlídli v analýze.

5.6.1. Testování během vývoje Nejdůležitějším testováním je tzv. unit testing, který se používá pro automatické ověřování funkčnosti psaného kódu. Základem je testování jednotlivých tříd a metod. Vývojové prostředí Eclipse disponuje rozsáhlou druhotnou kontrolou psaného kódu. V případě komplikace je tedy schopno vypsat případné kolize, či chyby v kódu. Poměrně dobrým testem může být záměrně škodící jednání. Tedy používání aplikace tak, abychom jí vystavili záměrné nestabilitě. Tipy pro testování uvádím v těchto bodech: 

Vyzkoušení změny orientace displeje (viz příloha níže)



Vypnutí aplikace jinými, než zavedenými postupy (např. tlačítkem zpět, či domů s opětovným navrácením do aplikace)



Násilné ukončení aplikace task managerem (ukončí všechny aplikace a promaže RAM) Příloha č. 25

BANKOVNÍ KALKULÁTOR: Zobrazení aplikace naležato – změna orientace displeje [fotografie].

58

5.6.2. 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. Příloha č. 26

BANKOVNÍ KALKULÁTOR: Příprava emulátoru [fotografie].

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. Důvodem je fakt, že mezi emulátorem a hardwarem počítače je softwarová vrstva operačního systému. K této vrstvě nemáme běžně přistup, existuje však tzv. hardwarová akcelerace, která umožňuje přistupovat emulátoru k hardwaru počítače mimo vrstvu operačního systému. Základním problémem je ovšem fakt, 59

že musíme emulovat instrukční sadu procesorů ARM, což je výpočetně velmi náročné. Obzvláště, když nedávné verze emulátoru uměly využít pouze jedno procesorové jádro počítače. Opačným aspektem může být i rozlišení displeje, které je stále jemnější a tak emulovat tablet (softwarově vykreslovat plochu displeje) je poměrně zajímavá výzva pro každé stolní PC. Takové řešení má však za následek občasné lagování, které může být u některých verzí Androidu velmi znatelné. 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.



SD Card: pokud hodnotu vyplníme, bude v emulátoru dostupná paměťová karta, na kterou můžeme instalovat aplikace.

60

BANKOVNÍ KALKULÁTOR: Nastavení virtuálního stroje pro účely testování [fotografie].

Pokud jsme si nastavením jistí, zvolíme tlačítko OK. 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:

61

Příloha č. 27

BANKOVNÍ KALKULÁTOR: Ukázka běhu emulátoru [fotografie].

5.6.3. Fyzické testování Druhým typem testování jsou zkušební testy na co možná největším počtu zařízení se systémem Android. Ideální je, pokud využijeme jak smartphony, tak i tablety. Tento typ testování bývá nejčastěji spojen s uvolnění tzv. betaverze. Tu si vybraní uživatelé nainstalují na svoje zařízení a běžným používáním aplikaci testují. V případě, že se vyskytne nějaký problém, je možné vše zaznamenat automatickým hlášením, které může být doplněno o systémový log. Taková zpráva je nejčastěji odesílána přímo do vývojářovy e-mailové schránky. Pro účely naší aplikace by důkladnější testování postrádalo smysl. Základní testy v emulátoru a telefonu jsou vypovídající, díky Obchodu Play, který podporuje komentáře, či zasílání notifikací o problémech, je poměrně snadné si bezvadnou funkčnost aplikace uhlídat.

62

5.7.

Ovládání aplikace Bankovní kalkulátor

Ovládání aplikace je velmi intuitivní a plně optimalizované pro běh na tabletech i chytrých telefonech. Základní částí je úvodní obrazovka hlavní aktivity, která sestává ze třech polí: Příloha č. 28

BANKOVNÍ KALKULÁTOR: Úvodní obrazovka [fotografie].

Výši úvěru uživatel vyplní v celých číslech prostřednictvím numerické klávesnice, která se aktivuje při vstupu do aplikace. Součástí tohoto zadávání je také kontrola správnosti údajů, kterou lze vidět na následujícím obrázku:

63

Příloha č. 29

BANKOVNÍ KALKULÁTOR: Kontrola správnosti zadaných údajů [fotografie].

Po zadání správných hodnot, které demonstruji na následujícím obrázku:

64

Příloha č. 30

BANKOVNÍ KALKULÁTOR: Správně vyplněná pole aplikace [fotografie].

Dojde ke spuštění výpočtů a výpisu produktů z databáze, která čítá 14 bankovních ústavů s třiadvaceti bankovními produkty. Řazení tohoto výpisu je vždy od nejvýhodnějšího produktu po nejméně výhodný. Demonstruji příklad úvěru na částku 55 000 Kč při době splácení 48 měsíců.

65

Příloha č. 31

BANKOVNÍ KALKULÁTOR: Výsledková část aplikace – výpis bankovních produktů [fotografie].

Ve výpisu se na prvním místě za daných podmínek zobrazí bankovní ústav GE Money Bank s produktem Expres půjčka, který nabízí nejlepší podmínky na trhu. Po rozkliknutí této nabídky uživatel zjistí výši RPSN, které v tomto případě činí 5.85 %, což je nejvýhodnější nabídka. Také případná sankce za předčasné splacení je v tomto případě nulová. Na druhé straně výpisu pak nalezneme nejhorší nabídku, která je demonstrována společností Komerční banka a.s., s produktem Perfektní půjčka a výší RPSN 17.11 %, tedy o 12 % více, než v prvním případě, která nabídla GE Money Bank. V aplikaci si lze také všimnout konečné částky, kterou splatíme bance, ta je v případě KB vyšší o cca 8.000 Kč:

66

Příloha č. 32

BANKOVNÍ KALKULÁTOR: Výsledková část aplikace – výpis bankovních produktů [fotografie].

V současné době poskytuje aplikace data od následujících finančních ústavů: 

Raiffeisenbank a.s.



UniCredit Bank



Komerční banka a.s.



Oberbank



Česká spořitelna a.s.



ČSOB a.s.



LBBW Bank CZ a.s.



GE Money Bank a.s.



mBank



CitiBank



ZUNO Bank



Air Bank a.s. 67



Era/Poštovní spořitelna



Sberbank CZ a.s.

Zobrazení nabídek je variabilní. Pokud uživatel zadá částku úvěru menší hodnoty a aplikace zjistí, že některé ústavy takto nízké půjčky nenabízejí, pak se daný ústav v nabídce neobjeví. Vzhledem k faktu, že se úrokové sazby i celkové podmínky úvěrů několikrát do roka mění, je nutné na tyto změny reagovat. Vedoucí mé práce, pan Ing. Háněl mi nabídl několik zajímavých řešení, od získávání údajů z webů bankovních ústavů, přes vytvoření webové databáze, ze které by čerpala aplikace přes internetové připojení, až po pevné hodnoty v aplikaci. Vhledem k tomu, že jsem nechtěl být závislý na internetovém připojení, zvolil jsem poslední možnost. Došlo k vytvoření již zmíněné databáze s pevnými parametry. Jakmile se podmínky u některých bankovních produktů změní, bude tato změna odražena ve formě OTA (Over The Air = aktualizace šířená vzduchem) aktualizace přes Obchod Play. Uživateli se v notifikační liště nabídne aktualizace, díky které bude aplikace disponovat nejnovějšími daty všech bankovních ústavů.

68

6. Distribuce aplikací prostřednictvím Obchodu Play V mezičase dokončení a testování aplikace je vhodné zamyslet se, jak budeme hotovou aplikaci distribuovat k uživatelům. Možností je několik, od oficiálních, které je spjato s tržištěm aplikací (AppStore u iOS, Store u WP, Play Store u Androidu), přes neoficiální, které reprezentují různá internetová úložiště, či tzv. „warez obchody“, které se obzvláště u Androidu těší velké oblibě (typickým příkladem je obchod Aptoide22). Uživatel na nich najde často ty samé aplikace, které jsou k dispozici oficiální cestou. U warez obchodů však za ně nemusí zaplatit ani korunu. Stinnou stránkou však bývá vysoká pravděpodobnost infikování daného zařízení mallwarem. Nejlepší možností bývá pokaždé využití oficiálního tržiště aplikací té, které platformy. Aplikace tak získá na důvěryhodnosti a díky propracovanému systému komentářů můžeme sledovat, jak jsou uživatelé s naší aplikací spokojeni. Dalšími výhodami je také fakt, že tato tržiště jsou předinstalována v každém Android zařízení, odpadá tedy nutnost instalace obchodů třetích stran a s tím spojená rizika infekce zařízení. Významným vylepšením Obchodu Play je nově možnost zakoupení i dalších multimediálních souborů, např. filmů, hudby, knih, atp.

22

Dostupné na adrese: http://www.aptoide.com/

69

6.1.

Registrace do Google Play

Před samotným rozhodnutím, kdy nahrajeme aplikaci do tržiště, musíme provést několik kroků, které povedou k bezproblémovému zveřejnění aplikace. Před tímto zveřejněním je každá aplikace kontrolována, a pokud nesplňuje požadavky Obchodu Play, může dojít k jejímu vyřazení. Pokud otestování v emulátoru a fyzickém zařízení proběhlo dobře, vyextrahujeme si ze složky aplikace soubor s koncovkou APK, poté budeme potřebovat obrázek ikony aplikace, který nám Eclipse také vygeneruje. Samozřejmostí je kontrola minimální úrovně SDK, která zaručí, na jaké verzi Androidu aplikace bezchybně poběží a také kontrola oprávnění <usespermission>. V našem případě si aplikace žádná oprávnění nežádá, což je zásadní indikátor důvěryhodnosti. Poté nám zbývá vymyslet název aplikace, u nás se jedná o Bankovní kalkulátor.

6.2.

Postup pro vložení aplikace na Google Play

Vstoupením do vývojářské konzole23 se nám otevře prostředí, které je velmi intuitivně zpracováno. Na počátku jsme vyzvání k zaplacení poplatku ve výši 25 $. Platit lze kartou, či prostřednictvím PayPal. Základem konzole je menu, ve kterém po nahrání aplikace sledujeme oblíbenost své aplikace, komentáře, případně statistiky stahování. Příloha č. 33

G.P.: DEVELOPER CONSOLE: prostředí konzole pro vývojáře [fotografie].

V této konzole klikneme na možnost zvolit aplikaci. Vybereme soubor s koncovkou APK. Jakmile dojde k uložení souboru, krok se obarví zeleně a my můžeme pokračovat na popis aplikace. Cílem je vytvořit trefný text, který vystihuje funkčnost a záměr aplikace, není podbízivý, ale přitom svojí atraktivitou zaujme případné uživatele. Součástí je vložení min. 2 screenů obrazovek. Pokud chceme přitáhnout i uživatele tabletů, vložíme screeny zhotovené

23

Dostupné na adrese: https://play.google.com/apps/publish/v2/

70

na 7“ a 10“ tabletu. Poté vložíme ikonu aplikace ve vysokém rozlišení a zařadíme aplikaci do správné kategorie. V našem případě jsou to Finance. Příloha č. 34

G.P.: DEVELOPER CONSOLE: vložení nové aplikace a následný popis aplikace [fotografie].

71

Poslední částí vkládání aplikace je úvaha nad možností nechat si za aplikaci zaplatit. Aby nám to Google Play ulehčil, je nutné si založit účet obchodníka. Většina fyzických osob tedy stejně zvolí možnost bezplatného stáhnutí a užívání svých aplikací. Součástí této stránky je také trh, na který chceme cílit. Logickou úvahou by byl celý svět. Ovšem, vzhledem k faktu, že je aplikace kompletně v českém jazyce, zvolil jsem v tomto případě pouze Českou republiku. Po schválení všech kroků má Google cca 12 hodin na to, aby byla aplikace řádně „nalinkována“ do obchodu. Konzole vytvoří hypertextový odkaz, který je možné již použít. Vyhledávání aplikace pomocí klíčových slov je zdlouhavý proces, v době psaní této práce toto vyhledávání fungovalo spíše na příjmení autora, než-li na název aplikace. Příloha č. 35

G.P.: DEVELOPER CONSOLE: Určení trhu, kde bude možné naší aplikaci stáhnout [fotografie].

V případě, že schválení aplikace proběhne bez komplikací, zobrazí se aplikace také v kategoriích, které jsme v konzoli nastavili. Konečný výsledek naší práce může vypadat nějak takto:

72

Příloha č. 36

Google Play: Vyhledání hotové aplikace v tabletu [fotografie].

73

7. Závěr Cílem této práce bylo analyzovat současný stav v oblasti vývoje mobilních aplikací pro mobilní platformy Apple iOS, Google Android a MS Windows a navrhnout a realizovat aplikaci pro platformu Android, která porovnává bankovní produkty v oblasti osobních úvěrů. Aplikace obsahuje databázi 14 v Česku nejrozšířenějších bankovních ústavů a celkem 23 bankovních produktů, které nabízejí. Na základě zvolené výše půjčky a data splatnosti aplikace vypočte výše měsíční splátky a celkovou částku splatnou bance u všech produktů. Podle těchto dvou parametrů lze také produkty řadit a vyhodnotit tak ten nejlepší. V popisu produktu nechybí ani informace o možnosti předčasného splacení úvěru nebo výpočet RPSN. Aplikace je dostupná z internetového úložiště Google Play24, díky kterému lze jednoduše aktualizovat. Aktualizace je nutná zejména kvůli neustále se měnícím sazbám jednotlivých produktů. Aplikaci by bylo do budoucna vhodné rozšířit např. o další produkty, kterými mohou být hypotéky, stavební spoření apod. Další možností rozšíření aplikace, je vytvoření funkčně identických klonů, které by fungovaly i na ostatních platformách, jako iOS či Windows Phone. V době psaní této práce neměla tato aplikace přímého konkurenta v Obchodu Play. Věřím tedy, že se najde mnoho uživatelů, kteří tuto aplikaci velmi rádi přivítají.

24

Dostupné na adrese: https://play.google.com/store/apps/details?id=cz.test.calculator

74

9. Seznam použité literatury 9.1. [1.]

Tištěné monografie


[2.]


[3.]

ALLEN, Grant. Android 4: průvodce programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2013, s. 656. ISBN 978-80-2513-782-6.

[4.]

KŘENA, Bohuslav a Radek KOČÍ, VUT FIT BRNO. Úvod do softwarového inženýrství: Studijní opora [online], s. 100. vyd. Brno, 2006.

[5.]

HEROUT, Pavel. Učebnice jazyka JAVA. Aktualizované vyd. České Budějovice: Kopp, 2011, s. 381, ISBN 978-80-7232-398-2.

[6.]

SKONNARD, Aaron, GUDGIN, Martin. XML – pohotová referenční příručka. Vyd. 1. Praha: Grada, 2006, s. 344, ISBN 80-247-0972-4.

[7.]

SAMUELSON, Paul A., NORDHAUS, William D. Ekonomie. Vyd. 18. Praha: NS Svoboda, 2007, s. 775, ISBN 978-80-205-0590-3.

[8.]

VALENTA, Michal, POKORNÝ, Jaroslav. Databázové systémy. Vyd. 1. Praha: ČVUT, 2013, s. 265, ISBN 978-80-01-05212-9.

75

9.2. [1.]

Elektronické monografie

WIKIPEDIA In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014. Dostupné z: http://cs.wikipedia.org

[2.]

ECLIPSE - The Eclipse Foundation open source community website. [online]. Dostupné z: https://www.eclipse.org

[3.]

GOOGLE

ANDROID

-

ANDROID

DEVELOPERS

[online].

Dostupné

z:

http://developer.android.com [4.]

STACK OVERFLOW [online]. Dostupné z: http://stackoverflow.com/

[5.]

ORACLE [online]. Dostupné z: http://www.oracle.com/cz/index.html

[6.]

CODE PROJECT: For those who code – section Android [online]. Dostupné z: http://www.codeproject.com/?cat=22

[7.]

MĚŠEC [online]. Dostupné z: http://www.mesec.cz/produkty/spotrebitelske-uvery/

76

Vývoj mobilních aplikací

Recommend Documents