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. Jakub Machalický Brno 2013

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.

OBSAH 7 Obsah 1 Úvod a cíl práce 9 1.1 Úvod.................................... 9 1.2 Cíl..................................... 10 2 Metodika 11 2.1 Postup vývoje............................... 12 2.1.1 Životní cyklus........................... 12 2.1.2 Iterační model životního cyklu.................. 13 2.2 Speciality vývoje mobilní aplikace.................... 14 2.3 Způsob testování............................. 15 2.3.1 Testovací sada pod Androidem................. 15 2.3.2 Testování na fyzických zařizení................. 16 3 Analýza problematiky 17 3.1 Chytré mobilní telefony......................... 17 3.2 Operační systém Android........................ 18 3.3 Trendy v aplikacích............................ 18 3.3.1 Action Bar............................ 18 3.3.2 Sliding Menu........................... 19 3.3.3 Springpad............................. 20 3.4 Informační systém Cetecho s.r.o..................... 20 3.4.1 O společnosti........................... 20 3.4.2 Současný informační systém................... 21 3.5 Požadavky na funkcionalitu....................... 24 4 Řešení 26 4.1 Cetecho API............................... 26 4.1.1 Kontextový diagram....................... 26 4.1.2 Data flow diagram........................ 29 4.1.3 Datové úložiště.......................... 33 4.2 Android Aplikace............................. 35 4.2.1 Schéma aplikace......................... 36 4.2.2 Komunikační protokol...................... 40 4.2.3 Uživatelské rozhraní....................... 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 ÚVOD A CÍL PRÁCE 9 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 RIM 1, 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 1Q13 podíl na trhu 1Q12 podíl na trhu Meziroční změna Android 75,0 59,1 79,5 ios 17,3 23,3 6,6 Windows Phone 3,2 2,0 133,3 BlackBerry OS 2,9 6,4-35,1 Linux 1,0 2,4-41,7 Symbian 0,6 6,8-88,5 Ostatní 0,0 0,4-83,3 Celkem 100,0 100,0 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 Cíl 10 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é platformy 2 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 METODIKA 11 2 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 12 2.1 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 JUnit 3. 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 ADT 4, 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 17 3 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 QWERTY 5 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. 6 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í.

3.2 Operační systém Android 18 3.2 Operační systém Android Android je operační systém vycházející z operačního systému Linux 7. 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 Alliance 8. 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. 8 Konzorcium skládající se z 84 firem spolupracujících na otevřených standardech pro mobilní zařízení

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 fragmenty 11. 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 Springpad 12. Ú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 Chrome 13. (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 Surface 14, 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 CMS 15 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 Informační systém Cetecho s.r.o. 22 Obrázek 5: Kontextový diagram Cetecho s.r.o. Tabulka 2: Informace o položkách kontextového diagramu Terminátor Popis Datové toky Vedení Vedení společnosti získává z informačního Statistiky <- společnosti systému statistické informace Správce zadává data do informačního Hlášení systému <- Správce IS systému a kontroluje správný běh Zadání dat -> jednotlivých komponent Zákazník získává informace o produktech, Info pro zák. <- Zákazník nabídkách a dalších komponentech systému Požadavek zák. -> a zadává do něj své požadavky a poptávky 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ý HTML 16 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 RGB 17 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 URL 18 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ámka 19 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Í 26 4 Ř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í(api 20 ), 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í informacemi 21. 21 Informace jsou data, kterým je dán význam

4.1 Cetecho API 29 4.1.2 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íče 22 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 sha1 23 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 (barva 25 a zrnitost 26 ) 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 Barva je napříč celou aplikací definována jednotně a to RGB kódem 26 Zrnitost se definuje skupinou 1 5

4.1 Cetecho API 33 4.1.3 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