Marketingová aplikace pro OS Android

Mendelova univerzita v Brně Provozně ekonomická fakulta

Marketingová aplikace pro OS Android Bakalářská práce

Vedoucí práce: Doc. Ing. František Dařena, PhD.

Brno 2013

Jakub Machalický

Rád bych využil tohoto prostoru pro poděkování všem šířícím své produkty, kterým věnují spoustu času, jako open-source. Zejména těm, jejichž produkty ve své práci využívám.

Zadání práce

Zadání práce

Prohlašuji, že jsem tuto práci vyřešil samostatně s použitím literatury, kterou uvádím v seznamu

Brno 2013

................................................................

6

Abstract Machalický, J. Marketing application for OS Android Brno, MENDELU 2013 Theses is focused on development of marketing application for operating system Android. Analyzes existing information system of Cetecho s.r.o. and determines communication interface between these two platforms.

Abstrakt Machalický, J. Marketingová aplikace pro OS Android Brno, MENDELU 2013 Práce se zabývá vývojem marketingové aplikace pro operační systém Android. Analyzuje stávající informační systém společnosti Cetecho s.r.o. a stanovuje komunikační rozhraní mezi těmito platformami.

7

OBSAH

Obsah 1 Úvod a cíl práce 9 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2 Cíl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 Metodika 2.1 Postup vývoje . . . . . . . . . . . . . . 2.1.1 Životní cyklus . . . . . . . . . . 2.1.2 Iterační model životního cyklu . 2.2 Speciality vývoje mobilní aplikace . . . 2.3 Způsob testování . . . . . . . . . . . . 2.3.1 Testovací sada pod Androidem 2.3.2 Testování na fyzických zařizení

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

11 12 12 13 14 15 15 16

3 Analýza problematiky 3.1 Chytré mobilní telefony . . . . . . 3.2 Operační systém Android . . . . . 3.3 Trendy v aplikacích . . . . . . . . . 3.3.1 Action Bar . . . . . . . . . 3.3.2 Sliding Menu . . . . . . . . 3.3.3 Springpad . . . . . . . . . . 3.4 Informační systém Cetecho s.r.o. . 3.4.1 O společnosti . . . . . . . . 3.4.2 Současný informační systém 3.5 Požadavky na funkcionalitu . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

17 17 18 18 18 19 20 20 20 21 24

4 Řešení 4.1 Cetecho API . . . . . . . . . 4.1.1 Kontextový diagram . 4.1.2 Data flow diagram . . 4.1.3 Datové úložiště . . . . 4.2 Android Aplikace . . . . . . . 4.2.1 Schéma aplikace . . . 4.2.2 Komunikační protokol 4.2.3 Uživatelské rozhraní .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

26 26 26 29 33 35 36 40 41

. . . . . . . .

. . . . . . . .

. . . . . . . .

5 Závěr 47 5.1 Diskuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.2 Podobné aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6 Literatura

50

7 Přílohy

52

SEZNAM OBRÁZKŮ

8

Seznam obrázků Obrázek 1: Nokia 9000

17

Obrázek 2: HTC Dream

18

Obrázek 3: Android Action Bar

20

Obrázek 4: Hlavní obrazovka aplikace Springpad

21

Obrázek 5: Kontextový diagram Cetecho s.r.o.

22

Obrázek 6: Struktura tabulky content_type_page

23

Obrázek 7: Kontextový diagram Cetecho API

27

Obrázek 8: Data flow diagram Cetecho API

29

Obrázek 9: Entitně relační diagram

33

Obrázek 10: Schéma Android aplikace

36

Obrázek 11: Snímek obrazovky: Hlavní nabídka

41

Obrázek 12: Snímek obrazovky: Novinky, detail novinky a postranní panel 42 Obrázek 13: Snímek obrazovky: Tři režimy zobrazení dekorů

43

Obrázek 14: Snímek obrazovky: Nabídka zobrazení a detail dekoru

43

Obrázek 15: Snímek obrazovky: Prázdná galerie, o společnosti a kontakt 44 Obrázek 16: Snímek obrazovky: Vyhledávání a výsledky hledání

44

Obrázek 17: Snímek obrazovky: Produkty a detail kategorie produktů 45 Obrázek 18: Snímek obrazovky: Nastavení a přihlašování

45

Obrázek 19: Snímek obrazovky: Hlavní stránka horizontálně

46

1

9

ÚVOD A CÍL PRÁCE

1

Úvod a cíl práce

1.1

Úvod

V posledních letech prochází používání webu a dalších internetových technologii velkými změnami. Zatímco v minulém desetiletí se veškerý vývoj odehrával na velkých obrazových panelech stolních počítačů, popřípadě přenosných počítačů, v posledních dvou letech se vše přesouvá na malé, mobilní obvykle kapesní zařízení. Skoro každý dnes vlastní chytré mobilní zařízení, které podporuje rychlé datové připojení prostřednictvím sítí mobilních operátorů a obvykle také wi-fi. Každý chytrý telefon obsahuje standardní operační systém, který povoluje instalaci různých aplikací. Na rozmezí mezi chytrými telefony a stolními počítači stojí tablety. Jejich obliba roste zejména v posledním roce. V těchto zařízeních dominuje několik operačních systémů. Největším hráčem na trhu je Android společnosti Google Inc, který vsadil na (zdánlivou) otevřenost systému, pravidelně uvolňuje velkou část zdrojových kódů svého operačního systému a výrobcům jej poskytuje zcela zdarma. Druhým největším hráčem je iOS od společnosti Apple, Inc Celé zařízení, hardware i software si vytváří firma sama. V korporátní sféře, zejména v letech minulých, dominovala společnost RIM1 , která nabízí své produkty pod značkou BlackBerry. Jedná se o firmu silně orientovanou na interní e-mailovou komunikaci a její maximální možné zabezpečení. Posledním velkým hráčem, který stoji za zmínku, je Microsoft se systémem Windows Phone. Tento systém je velmi uzavřený, ale oproti předchozím verzím šestkové řady, prošel velkými změnami směrem k lepšímu, současné verze jsou uživatelsky velmi příjemné a jejich prodeje rostou. Podíl zařízení na trhu ilustruje následující tabulka 1. Operační systém Android iOS Windows Phone BlackBerry OS Linux Symbian Ostatní Celkem

1Q13 podíl na trhu 75,0 17,3 3,2 2,9 1,0 0,6 0,0 100,0

1Q12 podíl na trhu 59,1 23,3 2,0 6,4 2,4 6,8 0,4 100,0

Meziroční změna 79,5 6,6 133,3 -35,1 -41,7 -88,5 -83,3 41,6

Tabulka 1: Podíl operačních systému na trhu (Jan Láska, 2013) Firemní komunikace se zákazníky se razantně mění v posledních letech, veškerá komunikace se přesouvá ze stolních počítačů do mobilních zařízení, které má uživatel neustále u sebe. V dnešní uspěchané době chce každý všechno zjistit v momentě, kdy 1

RIM je zkratka kanadské společnosti Research In Motion

1.2

10

Cíl

ho to napadne a ne čekat, až bude k dispozici velký počítač případně až se PC zapne. To jistým způsobem řeší telefonům uzpůsobený web, ale ten má několik nevýhod. Především nenabízí tolik možností jako nativní aplikace pro daný operační systém, ale hlavně žádný web nedosáhne rychlosti a komfortnosti běhu přímo dané aplikace. Další nespornou výhodou nainstalované aplikace je to, že ji jednoduše má každý přímo v telefonu a zapne ji jedním stisknutím tlačítka, nemusí složitě vyhledávat webovou stránku. Každý se občas dostane do situace, kdy se jen podívá do menu zařízení, aby se na chvíli nějak zabavil a i zde je prostor pro to, aby si prohlédl, co je nového u společnosti, od které aplikaci má. Zkrátka mobilní aplikace je moderní komunikační kanál, který by neměla ignorovat žádná z firem, protože má obrovský potenciál přílivu nových zákazníků či zvýšení hodnoty těch stávajících. Nastala doba, kdy i uživatelé samostatní dříve než se podívají po webových stránkách společnosti, tak zkoušejí na oficiálních distribučních kanálech dané platformy2 vyhledat aplikaci, která by jim pohodlně nabídla přesně ty informace, které hledají a to v co nejkratším čase. Naopak, pokud má firma svou stálou klientelu, velmi pravděpodobně si takový zákazník brzy pořídí chytré mobilní zařízení a bude potřebovat mobilní aplikaci, tak aby mohl k produktům své oblíbené společnosti přistupovat kdykoliv, kdekoliv a v co nejkratším čase. To si uvědomí každá firma a ty, které tuto situaci neřeší, velmi brzy začnou hledat způsoby uspokojení této potřeby. Moderní aplikace zastává několik funkcí. Informuje uživatele o aktuálním dění a novinkách, které by ho mohly zajímat. Nabízí možnost pořízení nového produktu. Nechává uživatele v neustálém kontaktu s firmou. Stálému uživateli nabízí neustále něco navíc, třeba formou věrnostní slevy, akčního produktu nebo nadstandardních funkcí. Pomáhá firmě získat informace o uživateli, díky nimž mu může nabídnout produkt na míru. Toto jsou hlavní principy, na které se hodlám v práci zaměřit. Potenciál odvětví mobilních aplikací je i důvodem, proč jsem si zvolil právě toto téma pro svou závěrečnou práci. Vím, že dnes je na trhu spousta společností vlastnících své aplikace, ale stejně tak je pořád spousta těch, kteří budou situaci řešit v nejbližší době. V tom vidím svou příležitost a zkušenost s vývojem takové aplikace bude velmi cennou praxí.

1.2

Cíl

Cílem práce je vyvinout aplikaci pro operační systém Android, která bude komunikovat s informačním systémem společnosti Cetecho s.r.o. Aplikace bude sloužit k cílené prezentaci podle aktuální situace na trhu a poskytování novinek společnosti svým zákazníkům. Jednou z hlavních funkcí má být vyhledávání podle uživatelem zadaných kritérii napříč celým katalogem firmy. Důraz je kladen na správné chování a zobrazování jednotlivých funkcionalit na roztříštěné platformě. Aplikace bude provozována zejména na tabletech a telefonech. 2

Google Play, Apple iTunes, Nokia Store a další

2

2

METODIKA

11

Metodika

Metodika návrhu a vývoje mobilní aplikace vychází ze zažitých paradigmat. Od vývoje aplikací pro osobní počítače se liší v několika aspektech. Každý softwarový produkt by měl mít následující vlastnosti: Udržovatelnost Software by měl být napsán tak, aby odpovídal měnícím se požadavkům zákazníků. Je to kritický atribut, neboť změny v softwaru jsou neočekávané v souvislosti se změnou podnikového prostředí Provozní spolehlivost Provozní spolehlivost softwaru má řadu charakteristik, včetně věrohodnosti a bezpečnosti. Provozně spolehlivý software by neměl být příčinou fyzické nebo ekonomické škody v případě chyby systému. Výkonnost Software by neměl využívat nehospodárně systémové zdroje, jako je paměť nebo procesor. Výkonnost tedy zahrnuje citlivost, dobu odezvy, rychlost použití paměti. Použitelnost Software musí být použitelný bez nepřiměřeného důrazu na úroveň zkušeností či znalostí uživatele, pro kterého byl navržen. To znamená, že by měl mít vhodné uživatelské rozhraní a adekvátní dokumentaci. Vývoj každého softwarového produktu je náročný proces. Hladký průběh celého procesu značně usnadní dodržení těchto principů: Princip abstrakce a modelování Hlavním cílem tohoto principu je snaha o rozdělení zkoumané problematiky na mentálně zvládnutelné části a pohled na data a funkce nebo pracovní postupy s nadhledem bez uvažování o technologických aspektech. Princip iterace Problematika se řeší postupně, po částech, krocích, vše je rozděleno časově, finančně i personálně. Jednotlivé iterace jsou ověřené a schválené. Princip strukturování Vychází z předchozího předpokladu , problematika strukturovaná do částí, podle použité metodiky. Princip životního cyklu Celý vývojový proces je podřízen předem vymezeným etapám, jejichž posloupnost je dodržována. Princip automatizace Cílem je použití specializovaného softwaru pro podporu všech etap vývoje. Všechny tyto principy tvoří výstavbu základní metodologie pro řízený vývoj softwaru.

2.1

Postup vývoje

2.1

12

Postup vývoje

Proces tvorby softwarového produktu je v softwarovém inženýrství nazýván životním cyklem vývoje. Ten začíná prvotním nápadem něco řešit nebo vylepšit pomocí IS/ICT v souladu s informační strategií podniku a končí likvidací produktu a výměnou za produkt jiný. Tato na první pohled jednoduchá definice v sobě skrývá mnoho dalšího a složitějšího. Životní cyklus se dělí na etapy: 2.1.1

Životní cyklus

Specifikace problému Cílem této etapy je posoudit realizovatelnost projektu a stanovit základní koncept systému, resp. vybrat z více alternativ a odhadnout náklady a přínosy projektu. Výsledkem je několik klíčových úvodních dokumentů, jako je zadání projektu, specifikace požadavků, koncept a plán vývoje systému a plán testování, úvodní studie. Úvodní studie je závěrečný dokument etapy. Analýza V analýze je tvořen abstraktnějši model, etapa návrhu je technologicky více konkrétní. Globální analýza zpodrobňuje základní požadavky na systém z předchozí etapy. Požadavky jsou podrobně konkretizovány jako požadavky funkční a datové, je určena jejích priorita, je vytvořena struktura systému. V analýze se tvoří konceptuální modely. Jsou to hrubé návrhy funkcí a datových struktur. Je ověřena jejich platnost a správnost a především úplnost. Jsou analyzovány všechny systémové funkce, provedeno rozdělení do subsystémů, výsledný model analyzuje tzv. logický model systému. Návrh Návrhová část je podpořena hrubou verzí technologického modelu pro zvolenou variantu technického a programového vybavení, tzv. výchozí technologický model systému. V podrobné analýze a návrhu se blíže specifikují předchozí modely až na úroveň, kdy je možné takový systém implementovat. Navíc dochází k návrhu uživatelského rozhraní. Výsledkem jsou detailní konceptuální modely funkcí a dat, musí být úplné a konzistentní, je vytvořen úplný technologický model systému, který vychází z globální analýzy. Obsahuje detailní návrh architektury systému, včetně popisu rozhraní a uživatelských obrazovek, v datovém modelu jsou konkretizovány struktury dat (typy, délky, přesnost, počáteční a konečné hodnoty). Implementace Jde o realizaci detailního návrhu v implementačním prostředí (tzv. implementační model), včetně testování, tvorba a ladění programů, úpravy nakoupených typových produktů. V této etapě se tvoří programová dokumentace a rovněž uživatelská příručka v tištěné nebo elektronické podobě. Nedílnou součástí této etapy je příprava pro konverzi dat, nebo příprava materiálů ze kterých se data budou do databází vkládat. Zavedení a testování produktu, dokumentace Cílem je instalace technického a programového vybavení, konverze stávajících dat, pořízení dat, které jsou do-

2.1

Postup vývoje

13

posud v papírové formě, vytvoření provozních pokynů a zaškolení uživatelů. Vše by mělo být provedeno tak, aby byl přechod na nový systém v organizaci pokud možno rychlý a bezpečný, pro uživatele co nejméně náročný. Zpočátku vše funguje ve zkušebním provozu (pomoc uživatelům osobními kontakty s integrátory, horké linky, příručky, sledování zkušebního provozu, opravy chyb). Jde o problematickou a kritickou část životního cyklu. Teprve po ověření vhodnosti systému pro běžný provoz a provedeni všech schvalovacích testů je dokončena implementace. Provoz, údržba a rozvoj produktu Cílem je zajistit bezproblémový provoz, průběžné aktualizace, zajištění bezpečnosti dat, údržba nejen programového systému, ale také aktualizace dokumentace a realizace změn. 2.1.2

Iterační model životního cyklu

Existuje několik používaných modelů vývoje. Nejčastějšími jsou Vodopád, Spirála, Prototypování a Iterační model. Vzhledem k způsobu komunikace se společností Cetecho s.r.o., jakožto zadavatelem projektu, byl zvolen poslední jmenovaný. Hlavními důvody použití této metody pro aplikaci firmy Cetecho s.r.o. je, že v každém kroku produkuje funkční, spustitelný celek. Zadavatel sám na počátku vývoje nevěděl přesně, co od aplikace chce a až pohled na danou funkcionalitu v praxi poskytl pohled na budoucnost dalšího vývoje a úpravy právě vytvořených funkcí. Tato moderní metodologie vývoje IS je aplikována na všeobecně uznávanou metodologii Rational Unified Processs (RUP). Ta byla vyvinuta jako komerční produkt dodávanou firmou Rational Software. Vývoj probíhá v iteracích, kde každá iterace je vlastně malý vodopád složený z etap tzv. pracovních postupů. Klíčovými pojmy jsou zde: • Iterativní vývoj softwaru, který využívá základní myšlenky detekce a odstraňování rizik ze spirálového modelu a přidává změnové řízení a znovupoužitelnost. • Správa a řízení požadavků spočívá v důsledné dokumentaci požadavků včetně data. priority, odpovědnosti, ceny. • Použití komponentové architektury pro efektivnější vývoj založený na znovupoužitelnosti komponent, šablon, stylů a pravidel. Komponentou rozumíme soudržnou část kódu ve zdrojové nebo spustitelné podobě s přesně definovaným rozhraním a přesně definovaným chováním. Komponenta je zapouzdřená a nahraditelná jinou komponentou se stejným rozhraním. Vodopádový životní cyklus vývoje SW platí pouze za předpokladu, že požadavky budou stálé, systém lze navrhnout na papíru, integrace nových funkcí se dá provést v krátkém čase, integrace nevnese nové chyby do systému. Pak se obecně dá říci, že první iterace odhalí největší rizika, všechny iterace produkují spustitelnou verzi, každá iterace obsahuje integraci a testování. První hrubé rozdělení životního

2.2

Speciality vývoje mobilní aplikace

14

cyklu je na fáze, všechny fáze mají několik iterací a každá fáze končí milníkem. Tyto fáze jsou následující: Zahájení, 10 % celkového času Vize projektu, definice obchodního případu, definice rozsahu projektu, milník Rozsah projektu. Příprava, 30 %celkového času Funkční požadavky, základní linie architektury, plán pro další fáze a další iterace, milník Architektura. Konstrukce, 50 % celkového času Výroba produktu tzv. beta verze, příprava nasazeni, milník Úvodní funkčnost. Předávání, 10 % celkového času Nasazení produktu do rutinního provozu, výroba médií a dokumentace, instalace, školení a podpora, milník Nasazení produktu. Jednotlivé milníky musí splňovat tyto požadavky: Rozsah systému Souhlas zadavatele s rozsahem systému a odhadem nákladů, porozumění požadavkům, definice rizik a priorit. Architektura Stabilní architektura, jeji popis, model use case, dodatečné požadavky, revidovaný seznam rizik a priorit, plán pro zbytek projektu. Úvodní funkčnost Funkční a stabilní verze systému, pokrytí požadavků, eliminace rizik, uživatelská dokumentace, vyhodnocení testů. Nasazení produktu Systém v rutinním provozu, vyškolení uživatele, fungující podpora, vyladěný výkon, vyhodnocení projektu a doporučení dalšího vývoje. Každá iterace obsahuje základní pracovní postupy, které zhruba odpovídají vodopádu: • Správa požadavků • Analýza a návrh • Implementace testování • Vyhodnocení plánu Všechny iterace obsahují dále podpůrné pracovní postupy, jako je řízení projektu, konfigurace prostředí nebo konfigurační řízení. Další pracovní postupy (pouze v první nebo poslední iteraci) mohou být obchodní modelování, úvodní plánování a dodání. (Ivana Rábová, 2008, s.35-44)

2.2

Speciality vývoje mobilní aplikace

Vývoj mobilních aplikací se v několika faktorech liší. Některé kroky můžeme přeskočit a naopak nad dalšími je nutné se zamyslet déle, než u vývoje klasického software.

2.3

Způsob testování

15

V tomto případě je práce velmi usnadněna tím, že je jasně stanovená platforma vývoje. To, jak by měla aplikace vypadat a fungovat, je jasně dáno sadou balíků a doporučení pro vývoj aplikací přímo od vývojáře operačního systému. Náročnější část spočívá především v testování dílčích částí.

2.3

Způsob testování

Vady softwaru mohou vést k selhání informačních systémů, což může mít za následek i značné škody. Z tohoto důvodu by měly být softwarové produkty testovány. Testování softwaru je proces, při kterém dochází k ověření, zda softwarový produkt odpovídá definovaným požadavkům. Za tímto účelem je software podroben sérii testů, kterými je softwarový produkt prověřen na několika úrovních, od jednotlivých programových komponent až po programový systém jako celek. Testování softwaru není samostatný proces, ale je součástí procesu vývoje softwaru. Proces vývoje softwaru popisují metodiky vývoje softwaru, které definují principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení. Metodik existuje velké množství a liší se zaměřením, rozsahem, oblastí, pro kterou jsou určeny, přístupem k řešení a v neposlední řadě také úrovní podrobnosti, na které jsou popsané jednotlivé postupy, procesy, doporučení, techniky a další složky metodiky. Rozdíly mezi metodikami nalezneme i v přístupu k testování softwaru, který při jeho vývoji uplatňují. Proces testování by sám měl být kvalitní, aby podával relevantní údaje o dosažené kvalitě produktu. Cílem tohoto článku je porovnat přístup k testování softwaru v několika vybraných metodikách vývoje softwaru a zhodnotit přínosy a případné slabé stránky těchto přístupů pro vývoj softwaru. (Alena Buchalcevová, Jan Kučera, 2008) 2.3.1

Testovací sada pod Androidem

Sada testovacích nástrojů, jakožto integrovaná součást vývojového prostředí, nabízí architekturu a silné nástroje, které pomáhají otestovat každý aspekt aplikace. Nástroje pro testování se skládají z těchto klíčových funkcí: • Testovací balík je založen na JUnit3 . Dá se použít čístě JUnit pro testování tříd, které nevyužívají Android API, a nebo nástavby JUnit pro ty, které Android API využívají. K dispozici jsou velmi obecné testovací třídy, ale i velmi pokročilé. • Rozšiřující balík JUnit pod Androidem zprostředkovává testy specifické pro jednotlivé komponenty. Tyto třídy poskytují pomocné metody pro vytváření fiktivních objektů a metod, které pomáhají řídit životní cyklus komponenty. • Testovací balíky jsou podobné hlavním aplikačním balíčkům, takže není třeba se učit nový soubor nástrojů a technik pro navrhování a budování testů. 3

JUnit je nástroj napsaný v jazyce Java určený pro jednotkové testy

2.3

Způsob testování

16

• Sada nástrojů pro tvorbu a testování jsou k dispozici v Eclipse s ADT4 , a také v příkazovém řádku pro použití s jinými vývojovými prostředími. • Android SDK také poskytuje Monkeyrunner, API pro testování zařízení s programem v Pythonu a UI/Application Exerciser Monkey nástroj příkazového řádku pro zátěžové testování uživatelského rozhraní zasláním pseudo-náhodné události do zařízení. (Google Inc., 2013) 2.3.2

Testování na fyzických zařizení

Přestože je k dispozici spousta nástrojů pro otestování veškerých funkcí i uživatelského rozhraní, je Android natolik roztříštěná platforma, že je třeba otestovat její chování na reálných zařízeních. Sebelepší simulátor nenahradí test aplikace, tak jak ji bude na svém zařízení používat koncový uživatel. Na trhu je dostupné nepřeberné množství těchto zařízení. (Ed Burnette, 2009) Pro testování jsem se rozhodl použít zástupce typického pro kategorii tohoto zařízení. Na testování budou použity: • Samsung Galaxy S Advance Zástupce střední třídy, 4”displej, dual core procesor, Android 2.3.6 • Samsung Galaxy Tab 8.9 Tablet, 8.9”displej, dual core procesor, Android 4.0 • Samsung Galaxy Mini 2 Zásupce nižší třídy, 3.2”displej, single core procesor, Android 2.3.6 • Samszng Galaxy S3 Zástupce vyšší třády, 4.7”displej, quad core procesor, Android 4.1 • Sony Ericsson Xperia Mini Pro Zástupce nižší třídy, 3.2”displej, single core procesor, Android 2.2 • ZTE Kis Plus Zástupce nižší třídy, 3.2”displej, single core procesor, Android 2.3 • Google Nexus S Referenční telefon, 4”displej, dual core procesor, Android 4.1 • Huawei Ascend Y300 Zástupce střední třídy, 4”displej, dual core procesor, Android 4

4

Eclipse s ADT je základní vývojové prostředí se zásuvným modulem pro praci s Android SDK

3

ANALÝZA PROBLEMATIKY

3

17

Analýza problematiky

Kapitola se zabývá důkladným prozkoumáním situace ohledně chytrých mobilních telefonů, jejích využití, historie, trendů v moderních aplikacích a důkladnou analýzou současného stavu informačních systému zadavatelské společnosti.

3.1

Chytré mobilní telefony

Chytrý mobilní telefon je zařízení, které používá standardizovaný operační systém, povoluje uživateli instalovat aplikace, případně i upravovat jednotlivé součásti systému. První zařízení, jež bylo možné nazvat chytrým mobilním telefonem, bylo patentováno v roce 1973. Konceptem bylo propojení umělé inteligence, zpracování dat a jejich následná vizualizace v rámci zařízení, které bylo rovněž schopno telefonovat. První skutečně použitelné zařízení přišlo až v roce 1996. Vyvinula ho společnost Nokia pod označením 9000. Jednalo se o kombinaci PDA a mobilního telefonu. Konstrukčně připomínal laptop. Navenek vypadá jako obyčejný, rozměrnější, telefon, ale po rozevření se uživateli zpřístupnila QWERTY5 klávesnice s velkým displejem. V 90. letech to byl nejprodávanější produkt této firmy. (Wikimedia Foundation, 2013)

Obrázek 1: Nokia 9000

Dnešní zařízení samozřejmě vypadají výrazně moderněji. Od roku 2008 se na určování trendů významnou vahou podílí společnost Apple Inc. se svým produktem iPhone. Jedná se o telefon s velkým dotykovým displejem a jediným tlačítkem. Celý systém je zaměřený na jednoduchost. Vydání tohoto telefonu můžeme považovat za začátek nové éry chytrých telefonů. 6 Apple Inc. 5

QWERTY je česká verze rozložení klávesnice vycházející z QWERTZ. Apple Inc. je kalifornská firma. Zpočátku byla zaměřena na vývoj osobních počítačů, dnes její zisky plynou především z vývoje chytrých, mobilních zařízení. 6

3.2

Operační systém Android

3.2

18

Operační systém Android

Android je operační systém vycházející z operačního systému Linux7 . Je speciálně upraven pro použití na zařízeních s dotykovými displeji a dalšímu moderními senzory. Sytém byl původně vyvíjen společností Android Inc, kterou finančně zajišťovala společnost Google, Inc a později, v roce 2005, ji celou odkoupila. Android byl veřejnosti představen v roce 2007 spolu se založením Open Handset Alliance8 . První telefon založený na Androidu se začal prodávat v říjnu 2008. Byl jím HTC Dream, též známý jako T-Mobile G1. Android je vyvíjen a distribuován pod licencí Apache

Obrázek 2: HTC Dream

3.3

Trendy v aplikacích

Android je velmi rychle vyvíjející se produkt. Dá se říct, že každý půl rok vyjde velká aktualizace, která přinese řadu optimalizací a softwarových novinek. V této kapitole vyzdvihuji ty, které jsou aktuální, a sami vývojáři systému se snaží tlačit na vývojáře aplikací, aby je využívali. 3.3.1

Action Bar

Action Bar je oblast v aplikaci, která příspívá k orientaci uživatele v aplikaci a zároveň mu poskytuje uživatelské akce a navigační prvky. Vývojový tým Androidu 7

Linux je je operační systém Unixové třídy vyvíjený jako open-source software. Konzorcium skládající se z 84 firem spolupracujících na otevřených standardech pro mobilní zařízení 8

3.3

Trendy v aplikacích

19

doporučuje použití tohoto prvku v naprosté většině aktivit,9 ve kterých uživatel potřebuje jakýkoliv druh akce nebo celkové navigace v aplikaci, protože Action Bar poskytuje uživateli jednotnou orientaci napříč různými aplikacemi. Stejně tak operační systém je navržený k optimálnímu zobrazení Action Baru na různých displejích či rozlišeních. Veškeré možnosti použití, chování a viditelnosti jsou dostupné pod Action Bar API, které je obsahuje Android OS od verze 3.0 (Honeycomb). (Mark L. Murphy, 2013) Hlavní cíle použití Action Baru jsou: • Poskytnout dostatečný prostor pro zobrazení značky aplikace a umístění v rámci aplikace. Toho je dosaženo pomocí ikony nebo loga aplikace na levé straně názvu aktivity. Pokud je aktivita jasně identifikována jinak, například grafickým odlišením aktivního tlačítka, je možné odstranit název aktivity a získat tak více prostoru pro uživatelské akce. • Poskytnout konzistentní navigaci a jasné zobrazení napříč různými aplikacemi. Action Bar nabízí zabudovanou navigaci pomocí tabů10 pro přepínaní mezi jednotlivými fragmenty11 . Action Bar rovněž nabízí drop-down seznam jako alternativní způsob ovládání nebo jako prostředek pro řazení/filtrováni obsahu aktuální aktivity. • Nabídnout přístup ke standardním prvkům, které jsou shodné ve většině aplikací (jako například hledání, sdilení atd.), neustálý a přístupný v předvídatelné podobě. Tyto tlačítka můžou být umístěny jednotlivě vedle sebe přímo v rámci Action Baru nebo ve skupině, která se zobrazí po vyvolání dialogového menu. Action Bar API je uzpůsobené k dynamické reakci na velikosti zařízení, kde aplikace právě běží a tlačítka, která se nevejdou, automaticky schová do dialogové nabídky. Na obr.3 je vidět typický Action Bar podle referenční příručky. Úplně nalevo je logo aplikace, vedle jsou čtyři tlačítka pro přepínaní tabů/fragmentů. V tomto příkladu je vynechán název aktivity, protože je jasné, kde se uživatel nachází podle aktivního tlačítka. Dále je tlačítko pro rychlé pořízení fotografie a úplně na pravo dialogová nabídka, kde jsou zároveň všechna další tlačítka, které se na Action Bar nevešla. (Google Inc., 2013) 3.3.2

Sliding Menu

Kontextové menu se může pouze objevit po stisknutí tlačítka. Pro lepší pocit z používání aplikace je jeden z požadavků animování zobrazení menu. K dispozici je 9

Aktivita je část Androidí aplikace, dalo by se jí přirovnat k jednotlivé stránce v rámci rozsáhlého webu 10 Tabem je v Androidu nazývána přepínací karta nebo záložka. 11 Fragment je podmnožinou aktivity. Aktivita se může skládat z několika fragmentů. Jejich obrovskou výhodou je různé zobrazení a rozložení fragmentů na různě velkých zařízeních, aplikace může tedy vypadat výrazně odlišně na Android TV a telefonu.

3.4

Informační systém Cetecho s.r.o.

20

Obrázek 3: Android Action Bar

rozšířující framework nazvaný Sliding menu. Pomocí něj se dá snadno animovat jakékoliv najížděcí menu. SlidingMenu je Open Source knihovna pro Android, která umožňuje vývojářům snadno vytvářet jezdící menu tak, jak je použito ve většině oblíbených aplikacích, např. Google+, YouTube nebo Facebook aplikace. Knihovnu lze volně využít v jakémkoliv projektu, kde je citován SlidingMenu projekt a zahrnuta licence v aplikaci. (Jeremy Feinstein, 2013) 3.3.3

Springpad

Mezi jeden z požadavků firmy bylo, aby aplikace fungovala a vypadala rozložením ovládacích prvků podobně jako aplikace Springpad12 . Úvodní obrazovka Springpadu se skládá z velkých čtyřúhelníku, každý vede do jiné kategorie. Aplikace obsahuje Action Bar se všemi standardními prvky. Panel je rozšířen o aplikační menu dostupné po stisknutí ikony se třemi pruhy. Toto menu(včetně stejné ikony) se využívá v moderních mobilních aplikacích velmi často. Stejnou ikonu obsahuje pro vyvolání hlavní nabídky i další z produktů společnosti Google Inc. - Google Chrome13 . (Spring2partners Inc., 2013)

3.4

Informační systém Cetecho s.r.o.

Informační systém je soubor lidí, technologických prostředků a metod, které zabezpečují sběr, přenos, zpracování a uchování dat za účelem tvorby prezentace informací pro potřeby uživatelů.(Jaroslav Král, 1998) 3.4.1

O společnosti

Společnost Cetecho s.r.o. se zabývá zpracováním umělého kamene kategorie Solid Surface14 , se specializací na umělý kámen značek Corian, LG Hi-Macs, Hanex, Montelli, Staron, Avonite a Swanstone. Realizují kompletní dodávky projektových celků, případně i jejich částí (bary, recepční pulty, umyvadla, umyvadlové desky, kuchyňské pracovní desky aj.). 12

Jedná se o aplikace určenou pro ukládání poznámek na server a jejich sdílení mezi více uživateli, zařízeními a platformami. 13 Jedná se o jeden nejpopulárnějších webových prohlížečů 14 Jako Solid surface jsou označovaný celistvé materiály beze spár.

3.4

Informační systém Cetecho s.r.o.

21

Obrázek 4: Hlavní obrazovka aplikace Springpad

3.4.2

Současný informační systém

Společnost v současnosti provozuje webový informační systém. Jeho součástí je i katalog nabízených dekorů z umělého kamene a mnoho dalších prostřednictvím webu dostupných aplikací. Vše běží ve webovém prohlížeči. Základem je CMS15 Drupal. Jedná se open source redakční systém se spoustou dostupných rozšíření. Drupal ukládá veškerý obsah a nastavení do MySql databáze. Způsob využití ilustruje kontextový diagram na obr.5.

15

CMS je Content management system, neboli počítačový program dovolující vytváření, editování a publikování nějakého obsahu

3.4

22

Informační systém Cetecho s.r.o.

Obrázek 5: Kontextový diagram Cetecho s.r.o. Tabulka 2: Informace o položkách kontextového diagramu

Terminátor Vedení společnosti Správce IS

Zákazník

Popis Vedení společnosti získává z informačního systému statistické informace Správce zadává data do informačního systému a kontroluje správný běh jednotlivých komponent Zákazník získává informace o produktech, nabídkách a dalších komponentech systému a zadává do něj své požadavky a poptávky

Datové toky Statistiky Info pro zák.

Drupal ke svému běhu a ukládání dat používá velké množství tabulek. V tomto případě jich je 108. Z informačního systému budeme chtít zobrazovat pouze data o nabízených produktech. Vše ostatní bude evidováno stranou. Veškeré informace o produktech jsou obsahem tabulek content_type_page a node_revisions. Jejich strukturu ilustruje obr. 6. Tabulky popisují všechny nabízené produkty a obsahují zdrojový HTML16 stránek na webu. V informačním systému bohužel nejsou vedeny jednotlivé hodnoty ve vlastních sloupcích, vyjma informací o zrnitosti a barvě a veškeré hodnoty bude třeba identifikovat a ořezat přímo ze zdrojových HTML kódů a full-textu. Tento princip ukládání dat silně degraduje využití databázového systému. Definice využití jednotlivých sloupců vid Primární klíč používaný k návaznosti na node_revisions a další tabulky. [integer] nid Klíč používaný k návaznosti na další tabulky. [integer] 16

HTML Hyper-text Markup Language je značkovací jazyk pro vytváření webových stránek.

3.4

Informační systém Cetecho s.r.o.

23

Obrázek 6: Struktura tabulky content_type_page

field_dalsi_text_value Sloupec pro ”další text”. Není využíván. [longtext] field_dalsi_text_format Sloupec identifikující styl formátování ”dalšího textu”. Není využíván. [longtext] field_color_code_value Veškeré produkty jsou zařazeny do skupin podle své barvy. Každá barevná skupina má svůj dvojpísmenný kód, který je v tomto sloupci evidován. [longtext] field_color_code_name Název skupiny identifikované dvojpísmenným barevným kódem. [longtext] field_brand_name_value Název značky výrobce produktu. [longtext] field_group_name_value Identifikátor skupiny daného výrobce. [longtext] field_grain_type_value Číselný identifikátor zrnitosti. [longtext] field_dominant_color_value RGB17 kód dominantní barvy produktu. [longtext] field_minority_color_value RGB kód minoritní barvy produktu. [longtext] uid Unikátní identifikátor, v tabulce vždy nastaven na hodnotu 1. [longtext] title Titulek stránky zobrazovaný jako název okna ve webovém prohlížeči. [varchar] 17

RGB je barevný model založený na míchaní červené, zelené a modré barvy.

3.5

Požadavky na funkcionalitu

24

body HTML kód stránky, v každé stránce lze získat informace zejména o názvu a URL18 obrázku produktu. [longtext] teaser Zdrojový HTML kód úvodního náhledu na produkt. [longtext] log Zápisy logu - není využito. [longtext] timestamp Časová známka19 data poslední změny produktu. [integer] format Identifikátor formátování stránky, zde vždy nastaven na hodnotu 2.[integer]

3.5

Požadavky na funkcionalitu

Aktuality Aplikace má umožnit zobrazovat aktuality a novinky zadané společnosti. Každá aktualita má svůj náhled a detail. Všechny mají být uložené na serveru a aplikace si vždy stahuje aktuální verzi s využitím cachování obrázků do paměti telefonu pro úsporu přenášených dat. Vzorníky Vzorníky slouží k zobrazení nabízených produktů zobrazených podle předem daných kategorii, ty jsou specifikovány značkami produktů od jednotlivých výrobců. Tato funkce má staticky dané kategorie, ale veškerý obsah se stahuje přímo ze současného informačního systému a odpovídá přesně zobrazení na webových stránkách. Hledání barvy a dekoru Aplikace musí být schopná vyhledávat napříč všemi vzorníky dle zadaných kritérií. Těmi jsou hlavní barva produktu, doplňková(minoritní) barva produktu a zrnitost. V návaznosti na vývoj mobilní aplikace bude zanesen do stávajícího informačního systému údaj o barvách v RGB formátu a zrnitost označená vlastní kategorií. Do budoucna má být aplikace schopna filtrovat obsah i podle dalších parametrů. Zdrojem veškerých dat je současný informační systém, stejná data jaká jsou použita u vzorníků. Veškeré výpočty mají probíhat na straně serveru tak, aby aplikace běžela naprosto plynule i na hardwarově slabších zařízeních. Produkty Jedná se o statickou sekci zobrazující příklady realizace hotových produktů firmy Cetecho s.r.o. Zde budou umístěny vybrané fotografie konkrétních produktů. U každé kategorie bude možné dostat se do fotogalerie, jejíž kategorie korespondují s kategoriemi této sekce. Fotogalerie Fotogalerie zobrazuje libovolné obrázky s krátkým popiskem. Zdrojem obrázků je stávající informační systém. Obrázky jsou tříděny do kategorii odpovídajících sekci Produkty. 18

Uniform Resource Locator je jednotný textový identifikátor popisující cestu k požadovanému souboru. 19 Formát UNIX_TIMESTAMP, jedná se o počet sekund od 1. ledna 1970.

3.5

Požadavky na funkcionalitu

25

O společnosti Cetecho Jedná se o sekci, ze které je přímo možné kontaktovat zastoupení firmy z důvodu dalších otázek, nebo třeba i poptávky po produktu. Kontakty Jedná se o mini sekci zobrazující kontaktní údaje, zobrazení na mapě a klíčová slova společnosti Cetecho s.r.o. Uživatelské účty Aplikace má být schopná vytvářet uživatelské účty a rozlišovat dostupnost jednotlivých funkcí v aplikaci podle úrovně aktivace účtu a země, ze které uživatel pochází. Vytvoření účtu probíhá přímo v aplikaci, ta odesílá e-mailovou zprávu obsahující náhodně vygenerované heslo tak, aby došlo k ověření existence zadaného e-mailu. Zemi aplikace rozpoznává na základě IP adres odkud požadavky pocházejí. Uživatelské účty jsou synchronizované se stávajícími účty v běžícím informačním systému. Oblíbené Každý registrovaný uživatel si může během procházení aplikace ukládat libovolné produkty do oblíbených jednoduchým stisknutím ikony pro přidání. Oblíbené se rovněž mají synchronizovat s daty uloženými na serveru, tak aby si uživatel mohl zobrazit své oblíbené produkty třeba i prostřednictvím webových stránek společnosti. Ovládací panel Nedílnou součástí aplikace je její ovládací panel. Ten má fungovat online a má poskytovat podporu základních funkcí aplikace, jako je přidávání novinek, nastavení citlivosti hledání, přidávání položek do fotogalerie, manipulaci s uživatelskými účty a kontrolování aktivit z aplikace dle jednotlivých zařízení. V těchto tabulkách jsou velice neoptimálně zvolené datové typy, spousta redundantních hodnot a nesmyslně zvolené indexy. Nicméně optimalizace systému není účelem této práce.

4

ŘEŠENÍ

4

26

Řešení

Vzhledem k požadované funkcionalitě je vývoj rozdělen do dvou částí. První z nich poběží na serveru společnosti. Jedná se o rozhraní(API20 ), které bude dolovat data z nesourodé databáze a přetvářet je do jednotného formátu, který bude dále zpracovávat druhá část a tou je aplikace běžící na koncovém zařízení s OS Android. Jelikož se jedná o univerzální rozhraní, je navrženo s ohledem na opakované použití i pro jiné koncové zařízení a aplikace. Těmi mohou být zařízení s aplikací pro ostatní mobilní platformy - Windows Phone 8, iOs a jiné. Rovněž jinou koncovou aplikaci může být zcela univerzální mobilní webová aplikace. Napojení aplikace na stávající systém ilustruje obr.7.

4.1

Cetecho API

Aplikační programové rozhraní nad současným informačním systémem poskytuje řadu funkcí. Je vytvářeno za účelem ulehčení komunikace mezi koncovými zařízeními a serverem společnosti. Dalším důvodem je zabezpečení celého systému. Díky API uživatel nemá možnost manipulovat s daty přímo, ale může přistupovat pouze k vraceným hodnotám, přičemž zde probíhá řada kontrol. 4.1.1

Kontextový diagram

Model vnějšího chování systému je prezentován kontextovým diagramem, což je zvláštní typ diagramu datových toků. (Ivana Rábová, 2008, s.49)

20

API je Application programming interface neboli rozhraní, obsahující funkce využitelné mezi dvěma oddělenými prvky

4.1

Cetecho API

27

Obrázek 7: Kontextový diagram Cetecho API

Terminátory Current IS Terminátor obsahující veškerá data současného informačního systému Administration Terminátor znázorňuje ovládací panel vedené společnosti, hlavními funkce jsou přidávání aktualit a obrázků, spravování uživatelských účtů, nastavování dílčích parametrů pro vyhledávání mezi produkty Android App Terminátor znázorňující koncovou aplikaci pod OS Android WP8 App Terminátor znázorňující koncovou aplikaci pod OS Windows Phone 8 iOS App Terminátor znázorňující koncovou aplikaci pod OS iOS Mobile web Terminátor znázorňující koncovou mobilní webovou aplikaci Datové toky from IS Datový tok z aktuálního informačního systému (veškerý obsah aplikace)

4.1

Cetecho API

28

to IS Datový tok do aktuálního informačního systému, vkládaná data, jako například registrační údaje, odesílaná poptávky a jiné API Info Datový tok obsahující zejména logy a informace o provozu Settings Uložení nastavení z administračního panelu User request and data Požadavky uživatele na jednotlivé funkce a uživatelská data Data from API Zpracovaná data ze stávajícího IS Data to Android, iOS, WP8, Mobile web Stejně formátovaný datový tok jako Data from API Proces Cetecho API je dále dekomponován. Tuto dekompozici zobrazuje data flow diagram na obr.8. Veškeré funkce zobrazené na tomto diagramu jsou zpracovány jak v rámci API, tak na straně koncové aplikace. API řeší získání dat z databáze Cetecho, odstranění redundancí a zformátování do protokolu totožného na obou stranách. Koncová aplikace prezentuje uživateli požadované výsledky a data z databáze se tak stávají informacemi21 .

21

Informace jsou data, kterým je dán význam

4.1

Cetecho API

4.1.2

29

Data flow diagram

Obrázek 8: Data flow diagram Cetecho API

Datové toky Login checked Potvrzení správnosti přihlašovacích údajů News list Seznam aktualit, obsahuje název, úvodní text a volitelně náhled obrázku Stored favorites Přenáší uložené oblíbené položky (jejich id) uživatele ze serveru do koncového zařízení

4.1

Cetecho API

30

News detail Detailní pohled na aktualitu, oproti News list obsahuje navíc celý text a všechny obrázky Token confirmation Potvrzení unikátního klíče22 List of decors Seznam produktů (dekorů) Search results Výsledek hledání podle zadaných parametrů Gallery images and data Obrazová a textová data zobrazovaná v galerii Users favorites Oblíbené položky uživatele (jejich id) přenášené ze zařízení na server k uložení User data Osobní údaje uživatele při registraci Data from IS Data přenášená z provozu API. Na základě těchto dat vytváření logů Data change Změna nastavení API nebo vkládání, editace či mazání záznamů v databázi Parameters Parametry pro nastavení vyhledávání. Parametry jsou jednak pevně nastavované a uložené v databázi a druhotně jsou to parametry zadané uživatelem (například barva, typ zrna) Login data Uživatelské jméno a heslo Favorites Oblíbené položky uživatele (jejich id) Requested id Požadavek na jednu konkrétní položku z databáze Saved token Uložený token na serveru. Token se musí shodovat s tím na serveru Login confirmation Potvrzení přihlášení Favorites list Přenesení uživatelových oblíbených položek z API do koncového zařízení Minispecifikace Login 1. Uživatel odešle zašifrované jméno a heslo (heslo jako sha123 otisk) 2. Proces zkontroluje, zda-li se shodují odeslané údaje s údaji z databáze 3. Pokud se shodují proces, vrátí true a vytvoří se uživatelský token, který se uloží v koncovém zařízení a na serveru 22

Token je unikátní klíč obsahující jednoznačnou identifikaci uživatele, zařízení a časovou známku platnosti, na základě tohoto šifrovaného klíče se může uživatelovo zařízení přihlásit a udržet přihlášené bez neustálého odesílání uživatelských údajů 23 Sha1 je hašovací funkce z různě dlouhého vstupu vytvářející konstantně dlouhý výstup z důrazem na to, aby i malá změna vstupu zásadně změnila výstup.

4.1

Cetecho API

31

4. Pokud se neshoduje proces vrátí false 5. Každý krok je logován včetně časových údajů, ip adres a výrobních čísel do logu serveru. News 1. Příchozí požadavek na stažení novinek 2. Z databáze se načtou všechny novinky a odkazy na obrazová data 3. V Api se poskládají do přenosového protokolu a vrátí se uživateli 4. Pokud neexistuje žádna aktualita, nevrátí se žádná data getFavorites 1. Kontrola autorizace uživatele, pokud není přihlášen vrací false 2. Načtení pole obsahující ID položek, které má daný uživatel v oblíbených 3. Poskládání do přenosového protokolu a vrácení na koncové zařízení 4. Pokud nemá uživatel žádné oblíbené, nevrací nic saveFavorites 1. Kontrola uživatelovi autorizace, pokud není přihlášen vrací false 2. Zachycení odeslaných dat ze zařízení 3. Zpracování do pole 4. Uložení do databáze 5. Potvrzení uložení newsDetail 1. Ze zařízení odeslán požadavek obsahující ID požadované aktuality 2. Vyhledání aktuality v databázi 3. Poskládání požadovaných dat do protokolu, pokud pod ID není článek nalezen vrací false checkToken 1. Odeslání tokenu ze zařízení 2. Pokud se token nenachází v databázi, vrací false 3. Pokud je aktuální datum vyšší než nastavená platnost,24 vrací false 24

Platnost tokenů je nastavena v administračním panelu

4.1

Cetecho API

32

4. Jinak vrací true getDecorList 1. Zkontroluje vstupní parametry, ty mohou být: značka, barva, zrnitost, skupina 2. Podle daných parametrů načte do pole z databáze požadované výsledky 3. Výsledky seřadí dle relevance a sestaví do protokolu a odešle do koncového zařízení 4. Pokud nevyhovuje žádný výsledek, tak vrací false Registration 1. Přijme data ze zařízení 2. Pokud chybí nějaký údaj, vrací příslušný chybový kód 3. Pokud nějaký údaj obsahuje nepovolené znaky, nebo je ve špatném formátu, vrací příslušný chybový kód 4. Pokud se v databázi nachází stejné uživatelské jméno, vrací příslušný chybový kód 5. Jinak vrací true a odesílá na zadaný e-mail náhodně vygenerované heslo SelectorSearch 1. Zachytí příchozí parametry (barva25 a zrnitost26 ) 2. Načtení parametrů daných konfigurací (krok a počet kroků) 3. Hledání probíhá cyklicky odečítáním kroku z RGB kódu, cyklus je definován počtem kroků, takto probíhá pro každou barvu 4. Pokud není během průchodu cyklem nalezen žádný vhodný výsledek, vrací false 5. Jinak vrací do protokolu sestavené a dle relevance seřazené výsledky Gallery 1. Vyhledá v databázi obrazová a textová data příslušející do dané kategorie definované zadaným ID 2. Sestavení do protokolu a vrácení do koncového zařízení 3. Pokud není nic nalezeno, vrací false 25 26

Barva je napříč celou aplikací definována jednotně a to RGB kódem Zrnitost se definuje skupinou 1–5

4.1

Cetecho API

4.1.3

33

Datové úložiště

Stávající informační systém je nezbytné rozšířit o další tabulky nutné k provozu API. Jak je vidět na obr.9, jsou zde vazby mezi tabulkou m_api_users a dalšími

Obrázek 9: Entitně relační diagram

tabulkami. Vazba s tabulkou m_api_favorites má kardinalitu 1:0..N proto, že uživatel může, ale nemusí, mít uložené oblíbené položky. Vazba stejného typu s tabulkou m_api_tokens je ze stejného důvodu. Situace, kdy uživatel nemá žádný token, může nastat, když je čerstvě zaregistrovaný, ale ještě se nikdy nepřihlásil. Naopak může mít N tokenů jednak proto, že může být současně přihlášený na více zařízeních, ale také proto, že se neplatné tokeny uchovávají uložené. Oproti tomu vazba mezi tabulkou m_api_imei má kardinalitu 1:1..N, protože výrobní číslo zařízení (imei) je odesláno už při registrace a nemůže tedy nastat situace, kdy uživatel nemá alespoň jedno registrované zařízení, ale opět jich může mít více než jedno. Další tabulky

4.1

Cetecho API

34

uchovávají svá data bez cizích klíčů. Podle nepsaných pravidel jsou všechny klíče číselné, začínají od nuly a mají nastavenou automatickou inkrementaci. Maximální možná hodnota primárního klíče je 2.147.483.647. Je tedy velmi nepravděpodobné, že by této hodnoty bylo dosaženo. m_api_users Tabulka, která uchovává většinu uživatelských údajů. username Unikátní uživatelské jméno password SHA1 otisk uživatelského hesla email Uživatelův e-mail, ověřený odesláním hesla na tuto adresu phone Telefonický kontakt na uživatele. Do budoucna plánováno vícestupňové ověření pomocí SMS registration_date Datum registrace email_confirm Boolean hodnota ověření e-mailu sms_confirm Boolean hodnota ověření telefonního čísla vip_confirm Boolean hodnota nadstandardních funkcí pro tento uživatelský účet country Země odkud uživatel pochází (detekce podle IP adresy) m_api_imei Tabulka přímo navázaná na tabulku m_api_users klíčem user_id. Slouží k uchovávání výrobních čísel zařízení, z kterých se uživatel přihlašuje. user_id Cizí klíč z tabulky m_api_users imei Patnáctimístné unikátní výrobní číslo koncového zařízení. m_api_tokens Tabulka přímo navázaná na tabulku m_api_users klíčem user_id. Slouží k uchovávání tokenů pro rychlé přihlášení. user_id Cizí klíč z tabulky m_api_users token Unikátní identifikátor vytvořený z výrobního čísla zařízení, IP adresy, časové známky a náhodného klíče. create_date Časová známka data vytvoření tokenu. m_api_favorites Tabulka přímo navázaná na tabulku m_api_users klíčem user_id. Slouží k uchovávání oblíbených položek uživatele. user_id Cizí klíč z tabulky m_api_users

4.2

Android Aplikace

35

dekor_id Unikátní identifikátor produktu, který uživatel označí jako oblíbený. m_api_gallery Tabulka uchovávající adresu uložených obrazovch dat a jejich popisků. text Popisek položky url Adresa uložených obrazových dat cathegory Kategorie položky, předem známa množina kategorii m_api_news(_eng) Tabulka aktualit a článků. Česká a anglická verze, příčemž mezi nimi je voleno automaticky. Pokud je uživatel české nebo slovenské národnosti, použije se česká verze, v opačném případě se použije ta anglická. name Název aktuality ve výpisu aktualit caption Úvodní krátký text pro nalákání uživatele text Kompletní text aktuality image Url adresa obrazových dat pro náhled článku nameDetail Název článku v detailním zobrazení captionDetail Úvodní text článku v detailním zobrazení imageDetail Url adresa obrazových dat pro detailní zobrazení m_api_nastaveni Univerzální tabulka pro uchování parametrů API. Je možné do ní vložit libovolný parametr a k němu přiřadit hodnotu, případně hodnoty. par Libovolný parametr val Libovolná hodnota

4.2

Android Aplikace

Aplikace pod operačním systémem Android používají vlastní terminologii pro některé funkce. Nejdůležitějším termínem, který je následujícím textu hojně zmiňován je Aktivita. Jedná se o komponentu, reprezentující uživatelské rozhraní, přes které může uživatel pracovat s aplikací. Například Android aplikace pro práci s kontakty obsahuje Aktivitu pro vytvoření nového kontaktu. Aplikace Telefon obsahuje Aktivitu pro zadání a vytočení čísla a aplikace Kalkulačka obsahuje Aktivitu pro zadání výpočtů. Aplikace může obsahovat jednu Aktivitu, jako jenoduchá Kalkulačka, ale

4.2

Android Aplikace

36

většinou jich obsahuje více. Příkladem může být složitější kalkulačka, obsahující rozšiřující panel pro složitější výpočty, třeba goniometrické funkce. (Dave Smith, Geoff Friesen, 2011, s.13) 4.2.1

Schéma aplikace

Aplikace je velmi účelná, neni zde prostor pro vyplňování prázdných míst redundantní grafikou. Každá položka v aplikaci má jasně danou funkci a měla by být dostupná co nejjasnějším a intuitivním způsobem. Schéma rozložení funkcionality aplikace ilustruje obr.10.

Obrázek 10: Schéma Android aplikace

Každá položka odpovídá jedné aktivitě v aplikaci. Po kliknutí na ikonu aplikace se spustí v menu zařízení aktivita Loading screen. Tato aktivita inicializuje komponenty pro další běh aplikace. Nejdůležitější je inicializace třídy HttpParser, která obstarává veškeré přenosy mezi aplikačním rozhraním a aplikací, rozděluje komunikační protokol na stanovené datové položky a odesílá data o provozu zařízení. Po inicializaci třídy pro http přenosy se spustí funkce checkToken. Tato funkce porovná uložený token v zařízení, pokud se shoduje a je platný, považuje zařízení a uživatele od spuštění aplikace za přihlášeného, v opačném případě dojde ke spuštění funkce

4.2

Android Aplikace

37

login, ale pouze pokud, jsou v zařízení uložené přihlašovací údaje. Pokud je uživatel zdárně přihlášen, následuje synchronizace jeho oblíbených položek s daty na serveru. Synchronizace probíhá tak, že cokoliv je uloženo na serveru, je vždy aktuální. Po přihlášení se tedy nahradí veškeré oblíbené položky těmi nové staženými. Nevzniká narůst datového přenosu, protože se přenáší pouze ID položek, a to v jedné http paketě formou textového řetězce. Naopak, při každém ukončení aplikace se ještě před vypnutím odešle paket s aktuálními oblíbenými položkami. Výhodou je jednoduchost řešení, a naopak nevýhoda spočívá v eventuální možnosti ztráty dat v případě, kdy zařízení pracuje v režimu on-line a před vypnutím aplikace dojde ke ztrátě spojení. Po úvodní inicializaci se spustí aktivita Home. Tato aktivita zobrazuje šesti položkovou úvodní stránku, kde každá položka vede k určité funkcionalitě. Aktivita obsahuje sadu funkcí pro výpočet velikosti zobrazení jednotlivých položek na základě režimu zobrazení, rozlišení displeje, velikosti displeje. Díky těmto funkcím je zajištěno korektní zobrazení na každém zařízení. Nedílnou součástí této aktivity je inicializace sliding menu, které běží na pozadí každé další spuštěné aktivity. Menu je dostupné po stisknutí tlačítka v levé části Action baru. Jeho zobrazení je doprovázeno animaci. Z tohoto menu a z šesti hlavních položek se dají spouštět další aktivity. Šest hlavních položek vede na: • Aktuality - News • Kontakty - Contact • O společnosti - About • Produkty - Products • Vzorníky - Catalog • Hledání barvy a dekoru - Search Z bočního globálního menu se lze dále dostat na: • Aktuality - News • O společnosti - About • Kontakty - Contact • Produkty - Products • Avonite - Catalog + parametr Avonite • Corian - Catalog + parametr Corian • Hi-Macs - Catalog + parametr Hi-Macs • Swanstone - Catalog + parametr Swanstone • Montelli - Catalog + parametr Montelli

4.2

Android Aplikace

38

• Staron - Catalog + parametr Staron • Lyric - Catalog + parametr Lyric • Hanex - Catalog + parametr Hanex • Nastavení - Settings Dále je napříč celou aplikaci dostupné kontextové menu po stisknutí, většinou hardwarového, tlačítka pro to určeného. V tomto kontextovém menu se nachází: • Exit - Exit • Nastavení - Settings Aktivita Exit má za úkol řádně ukončit veškeré další procesy, které se za běhu spustí, zaručuje, že aplikace zůstane ještě chvíli na pozadí, dokud se na server neuloží uživatelovy oblíbené položky. V aktivitě Nastavení uživatel spravuje své přihlašovací údaje, v budoucích verzích aplikace zde bude prostor pro volbu dalších parametrů, například ruční přenastavení země, jazyka a případně úpravu kontaktních údajů. Lze odsud spustit aktivitu Registrace, ve které uživatel může vytvořit svůj uživatelský účet. V ideálním případě uživatel zadává pouze své uživatelské jméno, díky tomu, že e-mail a telefonní číslo si aplikace načte sama ze zařízení, respektive SIM karty. Bohužel během testování této funkcionality bylo zjištěno, že někteří operátoři mají zablokovaný přistup k některým funkcionalitám. Z českých operátorů nelze načíst telefonní číslo ze SIM karet společnosti T-Mobile Czech Republic, a.s. Karty zbylých českých operátorů jsou přístupné. Naopak někteří výrobci nepovolí načíst aplikaci primárního e-mail zařízení a uživatel je nucen ho zadat ručně. Formuláře jsou dostupné i z důvodu, že je velmi pravděpodobné, že aplikace bude hojně využívána na zařízeních bez SIM karet (levnější tablety) a zařízeních, kde uživatel nemá zadaný žádný e-mailový účet. Formuláře kontrolují korektnost zadaných údajů. Pokud by i přes to byli zadány nekorektní údaje, například takové, které by mohli poškodit databázi, tak další kontrola probíhá na úrovni API a finální kontrola při vkládání do databáze. Pokud jsou všechny údaje správně vyplněny, uživateli je dáno na vědomí, že stisknutím tlačítka souhlasí s podmínkami používání aplikace27 . Pokud zadané uživatelské jméno už někdo používá, vrátí se příslušná chyba a uživatel je upozorněn. V opačném případě je na serveru vygenerováno pseudonáhodné heslo a je odesláno na zadaný e-mail. Tímto krokem je uvěřena správnost zadaného emailu, firma má velký zájem na získávání kontaktů na potencionální zákazníky. Do budoucna je plánováno ověření i telefonního čísla, za toto ověření uživatel získá nadstandardní funkce. Ověření bude probíhat SMS zprávou. Pokud celý proces registrace proběhne v pořádku, je uživateli rovnou nabídnuto zadání hesla pro rychlé přihlášení. Aplikace je v základu nastavena pro uchování přihlášení do chvíle, než se uživatel sám odhlásí, důvodem je předpoklad, že na jedno zařízení připadá jedna 27

Podmínky použití bude integrovány v momentě jejich dodání zadavatelem - firmou Cetecho s.r.o.

4.2

Android Aplikace

39

osoba. V případě nejmodernějších tabletů, kde byla implementována podpora více uživatelů, je vše ošetřeno systémově, protože uživatelský účet se uloží pouze pro právě přihlášeného uživatele. Druhou aktivitou dostupnou přímo odesláním formuláře z nastavení je přihlášení. Uživatel zadá své jméno a heslo, z hesla se vytvoří jeho SHA1 otisk, a dále pro ukládání a přenosy se používá právě ten. SHA1 se dá považovat za dostatečně bezpečný, rekonstrukce hesla otisku získaného tímto algoritmem není nemožná, ale je při nejmenším velmi náročná. Přihlašovací údaje se přenesou na rozhraní, zde se porovná jméno a otisk hesla s údaji v databázi. Pokud se údaje shodují vrátí se token, který se uloží v zařízení a dále se odesílá pro ověření každého požadavku. Token má limitovanou platnost a je vytvořen z id uživatele, časové známky, IMEI zařízení a IP adresy zařízení. Dohromady tvoří bezpečnou základnu pro jednoznačnou identifikaci. Platnost tokenu je ověřována při každém zapnutí aplikace, pokud je neplatný jednoduše se během přihlašovacího procesu vytvoří nový. Pokud přihlašovací údaje nejsou správně, vrací se false. První z šestice hlavních funkci jsou Aktuality. Jsou tvořeny samostatnou aktivitou. Veškeré aktuality jsou uložené na serveru a dá se nastavit, komu se budou zobrazovat a komu nikoliv, podle země, jazyka nebo i konkrétního uživatele. Při spuštění této aktivity se stáhnou všechny dostupné náhledy, je jen na administrátorovi ve společnosti, kolik jich bude. Každá obsahuje náhledový název, náhledový obrazový materiál a úvodní text, který by měl přitáhnout pozornost uživatele. Na serveru jsou uložené dvě jazykové verze a to česká a anglická. Pro Čechy a Slováky je základem česká verze a pro zbytek populace anglická. Jazyk se rozpoznává podle IP adresy příchozích požadavků. Do budoucna je plánováno, že si bude sám uživatel moci zvolit jazykovou mutaci, tato funkce není aktivní, protože nejsou stanovena pravidla pro rozhodování o zobrazení obsahu. Každá aktualita se dá dále otevřít v detailním zobrazení. Zde je k dispozici detailní název, detailní obrazový materiál, úvodní text a samotný text aktuality. Do detailního zobrazení se předává pouze id aktuality, kterou uživatel požadoval, a následně je samostatně stažena novým požadavkem z API. Je zde tedy prostor pro dostatečnou optimalizaci datových toků, kde pro náhledy mohou být použity pouze miniatury obrázků a pro detail již kvalitní zobrazení. Aktivita Kontakty je druhou hlavní funkcí a zároveň první pouze statickou. Její obsah se mění pouze při vydání aktualizace celé aplikace. Každý uživatel může tak najít telefonický, e-mailový kontakt a adresu společnosti, i když třeba jeho zařízení nemá aktuálně přístup k internetu. Pro pohodlí jsou všechny kontakty vedené jako odkazy a kliknutí na ně spouští příslušnou aplikaci (odkaz na web - webový prohlížeč, e-mailový kontakt základní webový prohlížeč a telefonický kontakt rovnou začne vytáčet číslo). Dále je možnost u fyzické adresy sídla společnosti otevřít mapovou aplikaci (která je přímo integrovaná v tomto operačním systému) se zobrazením pozice a nabídkou navigování přímo do sídla společnosti. Třetí funkcí je statická aktivita o společnosti. Jako jediná napříč celou aplikací na ni nic nenavazuje. Slouží pouze k prezentací firemních standardů a prohlášení

4.2

Android Aplikace

40

o zaručení kvality. Obsahuje argumenty, které dávají nerozhodnutým zákazníkům jasně najevo, proč zvolit právě společnost Cetecho s.r.o. Další dostupnou aktivitou z hlavní stránky jsou produkty. Zde jsou kategorizované příklady toho, co společnost v minulosti realizovala. Část této aktivity je statická, v každé kategorii se nachází několik realizací. Kategorie jsou: • Koupelny • Recepční pulty • Pracovní desky • Svítidla • Nábytek Poté, co uživatel projde statickou část, je zde ukryta funkce galerie. V galerii jsou produkty rozčleněny do skupin stejně jako u produktů. V administraci rozhraní je zde i možnost vytváření dalších skupin, v dalším rozšíření aplikace bude galerie více rozšířena. U každé položky v galerii je kromě obrazového materiálu i krátký popisný text. Veškeré tyto informace se přidávají přes webové rozhraní administrace, kam se rovnou mohou pohodlně nahrát na server a rozhraní je zpracuje do kompatibilních rozměrů. Vzorníky a vyhledávání spouštějí stejnou aktivitu, avšak s úplně jinými parametry. V případě vzorníků je předán jediný parametr a tím je značka dekoru. Na základě té jsou zobrazeny všechny výsledky. Aktivita je samozřejmě plně dynamická a stahuje aktuální výsledky ze serveru. Je zde možnost různého zobrazení. Tím základním je seznam, kde se zobrazuje název, popisek, skupina a hvězdička pro přidání do oblíbených položek28 . Druhou možností je zobrazení dvou dekorů vedle sebe, zde se stále zobrazují název, popisek a hvězdička, ale nyní pod obrazovým náhledem a ne vedle něj. Poslední možností je zobrazení velkých náhledů nazvaných jako Galerie. V tomto režimu se zobrazuje pouze obrázek bez dalšího textu nebo hvězdičky. Ve všech třech režimech se uživatel může dostat do navazující aktivity, kterou je detailní náhled. Zde se zobrazí veškeré dostupné informace a samozřejmě, že je zde možnost přidání či odebrání položky z oblíbených. Na různých zařízeních může nastat problém s množstvím dat, které dokáže přístroj naráz načíst a dynamicky vykreslit. Proto je zde test výkonnosti a podle jeho výsledků určí algoritmus správný počet položek na stránku. Postupné dynamické načítání bude jedním z hlavním prvků optimalizace příští verze. 4.2.2

Komunikační protokol

Existuje spousta možností pro přenášení dat mezi serverem a koncovou aplikací. Je možné vytvořit úplně vlastní protokol, sestavovat pakety, kontrolovat jejich správ28

Hvězdička je zašedlá pokud položka není v oblíbených, po přidání položky do oblíbených zežloutne

4.2

Android Aplikace

41

nost a další funkce. Pro jednoduchost s přihlédnutím k typu dat, které se budou přenášet, bude aplikace používat HTTP. Pod zkratkou HTTP se skrývá Hypertext transfer protokol. Používají ho aplikace komunikující po webu. Jeho největší a nejznámější výhodou je dvoucestná konverzace mezi klientem a serverem. (David Gourley, Brian Totty, 2002, s.13) Pro odchozí požadavky se používá metoda GET, definice proměnných je obsažena v hlavičce paket. Příchozí požadavky do aplikace jsou realizovány pomocí textového řetězce v těle pakety s předem známým oddělovačem29 . Pro odesílání dat, zejména při registraci, se používá metoda POST, data jsou opět v hlavičce pakety. Citlivé údaje jsou šifrovány a heslo se nikdy nepřenáší v čitelné podobě, ale vždy pouze jako SHA1 otisk hesla. V příští verzi by bylo velmi vhodné využití JSON. 4.2.3

Uživatelské rozhraní

Uživatelské rozhraní bylo zvoleno zadavatelem. Rozvržení jednotlivých komponent přesně odpovídá zadanému konceptu. Na obr.11 je vidět rozložení hlavní stránky

Obrázek 11: Snímek obrazovky: Hlavní nabídka

spolu s kontextovým menu vyvolaným dialogovým tlačítkem. Dále ukazuje kombinaci hlavní stránky, postranního a kontextového menu a čisté hlavní stránka. Obr. 12 zobrazuje výpis novinek s testovacími daty a rozvržení zobrazení v detailním pohledu a kombinací hlavní stránky a postranního menu. Na obr.13 je ukázáno, jak vypadají jednotlivé režimy zobrazení dekorů v nabídce. První je klasické seznamové zobrazení. Následuje dvojseznamové zobrazení a posledním je galerie. Obr.14 de29

Oddělovačem je řetězec znaků ”-#-”

4.2

Android Aplikace

42

Obrázek 12: Snímek obrazovky: Novinky, detail novinky a postranní panel

monstruje dialogovou nabídku pro přepnutí typu zobrazení. Dále je zde vidět, jak vypadá detail dekoru. Rozdíl mezi obrazovkami je v přidání do oblíbených. Galerie, která neobsahuje žádné další obrázky, je vidět na obr.15. Dále jsou zde statické funkce O společnosti a Kontakt. Vyhledávání dekorů podle barvy a typu zrna ukazuje obr.16. První část ukazuje obrazovku bez zvolených parametrů. V druhé části lze vidět jak to vypadá, když se zvolí zelená barva a typ zrna Solid. Třetí ukazuje výsledky hledání.30 Nabídka produktů je vidět na obr.17. Uprostřed je vidět detail produktu a napravo tlačítko na prokliknutí do galerie. Galerie je vidět na obr.15. V nastavení uživatel zadává své uživatelské jméno a heslo, případně se přihlašuje nebo odhlašuje. To ukazuje obr.18. Dále je zde vidět obrazovka při procesu přihlášení a chybový výstup v případě, že přihlášení selže. Celá aplikace, vzhledem k optimalizaci pro tablety, pracuje i v horizontálním režimu. Veškeré rozmístění se přepočítává podle prostoru, který je na displeji k dispozici. Zobrazení horizontální hlavní nabídky na displeji telefonu demonstruje obr.19.

30

Může se zdát, že vyhledané barvy nejsou zelené, ale aplikace je nastavena tak, aby vždy nabídla uživateli nejbližšího možného kandidáta.

4.2

Android Aplikace

Obrázek 13: Snímek obrazovky: Tři režimy zobrazení dekorů

Obrázek 14: Snímek obrazovky: Nabídka zobrazení a detail dekoru

43

4.2

Android Aplikace

Obrázek 15: Snímek obrazovky: Prázdná galerie, o společnosti a kontakt

Obrázek 16: Snímek obrazovky: Vyhledávání a výsledky hledání

44

4.2

Android Aplikace

Obrázek 17: Snímek obrazovky: Produkty a detail kategorie produktů

Obrázek 18: Snímek obrazovky: Nastavení a přihlašování

45

4.2

Android Aplikace

Obrázek 19: Snímek obrazovky: Hlavní stránka horizontálně

46

5

ZÁVĚR

5

47

Závěr

Cílem této práce byl vývoj marketingové aplikace pro Android. Celý vývoj byl rozdělen do několika samostatných částí. Jedním z prvních témat bylo analyzování platformy a důkladné prozkoumání trendů toho, jak by taková moderní aplikace měla vypadat. Toto téma bylo probíráno v rámci několika schůzek se zadavatelem. Jakmile bylo stanoveno, jak by aplikace měla fungovat, následoval návrh principu fungování. Celá aplikace běží na principů tří vrstev. První z nich je serverová část, a to stávající informační systém společnosti Cetecho s.r.o. Ten byl dále rozšířen o prvky nutné k provozu druhé vrstvy, která rovněž funguje v rámci serveru. Je jí Cetecho API. To je rozhraní mezi koncovými zařízeními a stávajícím informačním systémem. Tato vrstva zprostředkovává nesourodá data z různých částí stávající databáze a přetváří je do jednotného a zabezpečeného formátu. Předmětem dalšího zkoumání a návrhu byl i komunikační protokol mezi aplikačním rozhraním a koncovou aplikací. To bylo poměrně jednoznačně zvoleno a postupem času se ukazuje toto rozhodnutí jako velmi správné. Největší částí vývoje aplikace byla práce na samotné koncové aplikaci a její následné testování. Pro vývoj byl zvolen iterační model, kde každá nová verze přináší spustitelnou verzi. Každá tato verze byla podnětem rozsáhlého testovaní. Na testování se podílel i zadavatel a během vývoje bylo možné, aby své požadavky dynamicky upravoval na základě výsledků. Výsledek je zdárně splněn a hotová aplikace je připravena pro uvedení na oficiální distribuční kanál Google play. Věřím v mohutné praktické uplatnění a budoucí nárůst tržeb právě díky této aplikaci. Do budoucna je plánována další práce na aplikaci. Řada rozšíření je známa už nyní. Jsou jimi zejména: JSON pole Pro komunikaci mezi rozhraními využití JSON polí místo textových řetězců Optimalizace vykreslování Při načítání většího množství dat optimalizovat jejich vykreslování, tak aby se aplikace nemohla potýkat se softwarovými bezpečnostními limity Parametry vyhledávání Zpřístupnění dalších parametrů pro vyhledávání. Zejména podle minoritní barvy. Tato funkcionalita je již implementována, ale není zpřístupněna Sociální sítě Integrace sociálních sítí, zejména facebooku, kde společnost má řadu odběratelů. Přidání možnosti sdílení libovolné položky a možnosti označení ”To se mi líbí”

5.1

Diskuse

Aplikace funguje stabilně na všech běžně dostupných zařízeních s Androidem.

5.2

Podobné aplikace

48

Během vývoje se značně měnily požadavky na její funkcionalitu. Uskutečnila se řada setkání se zadavatelem, kde bylo několikrát redefinováno, k čemu by aplikace měla sloužit. Během první schůzky bylo rozhodnuto, že aplikace by neměla mít žádné dostupné hledání, ale pouze interní funkci, která by se projevovala tak, že ke každému vybranému dekoru by přidala několik podobných. Podobnost měla být hodnocena podle barvy a velikosti zrna, ale také z velké části podle výhodnosti prodeje. Na druhé schůzce bylo od této funkce ustoupeno, s tím, že uživatel sám by si měl moci definovat, co vlastně hledá. Byla domluvena řada parametrů hledání. Od těch základních, kterými jsou barva, zrno, přes minoritní barvy, názvy barev až po statistiky prodejnosti pro daný typ produktu. V rámci ergonomie celé aplikace bylo od této funkce ustoupeno a vzniklo hledání tak, jak je dostupné v aktuální verzi. V systému existuje hledání podle minoritní barvy, zpřístupnění této funkce se plánuje v budoucích verzích. Na třetí a dalších následných schůzkách se začaly stanovovat pravidla, kdo, jak a za kolik bude moci vlastně aplikaci používat. Omezení měly být daná státem odkud je uživatel tím, jestli u firmy nakupuje, nebo jen hledá produkty, nebo třeba i tím, kolik si zaplatí za prémium služby. Hledání mělo být jednou z prémiových služeb. Od tohoto bylo nakonec ustoupeno a omezení jsou dány jen na jazykové mutace a toho, jestli je uživatel přihlášen či nikoliv. V příloze jsou obsaženy dokumenty zhotovené jako záznamy ze schůzek se zadavatelem.

5.2

Podobné aplikace

V odvětví zpracování kamene neexistuje žádná podobná aplikace. Většina katalogů je tvořena desítkami kufříků obsahujících natištěné vzory, případně přímo kousky kamene. Tato aplikace dovoluje hledání nejen v rámci všech značek, ale umožňuje snadno uživateli najít právě to, co hledá a to bez přehrabávání se několika vzorníky. Velkou část hodnoty aplikace tvoří data, která zadavatel sám přidá do svého informačního systému. Aplikací pro podporu prodeje a zvýšení konkurenceschopnosti je několik. Rád bych zde zmínil následující: Můj McDonald’s Aplikace Můj McDonald’s vám umožní mít neustále k dispozici všechny slevové kupony. Zároveň kdykoliv zjistíte, kde jsou nejbližší restaurace a budete mít přehled o všech produktech, které se v McDonald’s prodávají. Nezapomeňte, že jen díky aplikaci Můj McDonald’s máte k dispozici unikátní slevové kupóny i v době, kdy žádná velká kupónová akce neběží! (Google Inc., 2013, 2013) Aplikace nabízí katalog produktů, tím se značně podoba aplikaci Cetecho, ta má řadu funkcí navíc, například hledání podle preferencí, ukládání oblíbených položek a synchronizaci s webovou verzí dostupnou z jakéhokoliv webového prohlížeče.

5.2

Podobné aplikace

49

TESCO Potraviny online Mobilní aplikace ”TESCO Potraviny online”přináší jedinečnou možnost nakoupit přímo z mobilního telefonu. Díky ní nakupíte odkudkoliv, bez front a s dovážkou pohodlně až domů. Jednoduše si vyberte zboží z široké nabídky, vložíte do košíku a zvolíte čas doručení. Můžete přidávat jednotlivé položky mezi oblíbené, listovat zbožím v akci i organizovat nákupní seznamy podle toho, jak často dané výrobky nakupujete. Nákupní seznam navíc můžete odeslat emailem třeba svému partnerovi. (Google Inc., 2013) Jedná se aplikaci pro rychlý nákup potravin. Navíc nabízí přímý nákup z aplikace. To je u tak spotřebního zboží, jako jsou potraviny, logický krok. Oproti Cetecho aplikaci nenabízí žádný informační zdroj mimo nabídku produktů. Jinými slovy, nedává uživateli žádný důvod zapnout aplikaci, pokud nechce zrovna něco koupit. Jsem přesvědčen, že pokud by aplikace motivovala uživatele častěji ji zapínat, často by si něco koupil, i když předtím neměl zdání, že si něco chce koupit.

6

6

LITERATURA

50

Literatura

RÁBOVÁ, I. Podnikové informační systémy a technologie jejich vývoje. Brno: Tribun EU, 2008, ISBN 978-80-7399-599-7. BUCHALCEVOVÁ, A., KUČERA, J., Hodnocení metodik vývoje informačních systémů z pohledu testování. Systémová integrace, 2008, roč. 15, č. 2, s. 42–54. ISSN 1210-9479 . SMITH, D.,FRIESEN, G. Android recipes: a problem-solution approach. New York: Distributed to the book trade worldwide by Springer Science Business Media, c2011, xiii, 442 p. ISBN 978-143-0234-142.. GOURLEY, D., TOTTY, B. HTTP: the definitive guide. 1st ed. Sebastopol, 2002, xviii, 635 p. ISBN 15-659-2509-2. KRÁL, J. Informační systémy: specifikace, realizace, provoz. 1. vyd., 1998. 358 s. ISBN 80-86083-00-4. TESCO Potraviny online - Aplikace pro Android ve službě Google Play [online].Mountain View (CA): Google Inc. 2013 [cit. 2013-04-29]. Dostupné z: http://play.google.com/store/apps/ details?id=cz.anywhere.itesco. Můj McDonald’s - Aplikace pro Android ve službě Google Play [online]. Mountain View (CA): Google Inc. 2013 [cit. 2013-04-29]. Dostupné z: http://play.google.com/store/apps/details? id=com.omnicommediagroup.mujmcdonalds. Action Bar. In: Android Developers [ online ]. Mountain View (CA): Google Inc. , 1998-2013, 17. 03. 2013 [cit. 2013-03-17]. Dostupné z: http://developer.android.com/. Jfeinstein10 / SlidingMenu. In: SlidingMenu [ online ]. Jeremy Feinstein 20112013, 17. 03. 2013 [cit. 2013-03-17]. Dostupné z: http://github.com/jfeinstein10/SlidingMenu. About. In: Springpad [ online ]. Charlestown (MA): Spring2partners Inc., 2005-2013, 17. 03. 2013 [cit. 2013-03-17]. Dostupné z: http://springpad.com/about. Testing Fundamentals. In: Android Developers [ online ]. Mountain View (CA): Google Inc. , 1998-2013, 17. 03. 2013 [cit. 2013-03-17]. Dostupné z: http://developer.android.com/tools/testing/testinga ndroid.html. Smartphone. In: Wikipedia: the free encyclopedia [ online ]. San Francisco (CA): Wikimedia Foundation, 2001-2012, 30. 11. 2012 [cit. 2013-01-30]. Dostupné z: http://en.wikipedia.org/wiki/Smartphone.

6

LITERATURA

51

LÁSKA, J. Microsoft předstihl BlackBerry, mobilním platformám kraluje Android. [ online ]. 2013 [cit. 2013-05-20]. Dostupné z: http://www.mobilmania.cz/bleskovky/sc4-a-1323732. MURPHY, M.L., 2011 Android 2 : průvodce programováním mobilních aplikací. 1. vyd. Brno: Computer Press, 2011. 375 s. ISBN 978-80-251-3194-7. BURNETTE, E. Android: Introducing Google’s Mobile Development Platform. 1. vyd. Raleigh: Pragmatic Bookshelf, 2009. ISBN 1-9343-5656-5.

7

7

PŘÍLOHY

Přílohy

Přiložené CD obsahuje následující soubory: bp.pdf, bp.tex Elektronická verze této práce schuzky.zip Záznamy ze schůzek a podklady pro návrh uživatelského rozhraní CetechoAssistent.apk Spustitelný soubor se samotnou aplikací API.zip Zdrojové soubory API APP.zip Zdrojové soubory aplikace

52