Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství

Magisterská práce

Kniha jízd Bc. Lukáš Němeček

Vedoucí práce: Ing. Rastislav Maskaľ

10. května 2012

Poděkování Rád bych poděkoval Ing. Rastislavovi Maskaľovi za pomoc při sepisování zadání a za odborné vedení při vypracování diplomové práce na téma Kniha jízd. Neocenitelnou pomoc poskytl také Ing. Michal Foltýn zejména při konzultacích a implementaci serverové části v prostředí Sharepoint a frameworku Hermes.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů . Dále prohlašuji, že jsem s Českým vysokým učením technickým v Praze uzavřel dohodu, na základě níž se ČVUT vzdalo práva na uzavření licenční smlouvy o užití této práce jako školního díla podle §60 odst. 1 autorského zákona. Tato skutečnost nemá vliv na ust. §47b zákona č. 111/1998 Sb., o vysokých školách, ve znění pozdějších předpisů.

V Praze dne 10. května 2012

..................... 7

České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Lukáš Němeček. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Lukáš Němeček. Kniha jízd: Magisterská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract This thesis offers a solution for tracking business trips and fuel consumption for small and medium companies disposing of company cars. This solution is divided into two separate functional units - mobile application for Windows Mobile 7, which aims to simplify the entry of new business trips directly in the car, and the administration interface running in Sharepoint environment where you can manage cars, users and all inserted records. The work has theoretical and practical character. Main part is devoted to the description of the problem and technologies which application is based on. A separate section is devoted to a relatively new mobile platform Windows Phone 7. A substantial part of the thesis consists of mobile application, so the emphasis is on user interface and usability of application. Further in thesis Sharepoint is introduced, as technology spread among companies, and the entire infrastructure of the proposed solution. Keywords business car log book, car evidence, trip tracking, fuel consumption tracking, windows phone 7, sharepoint

9

Abstrakt Diplomová práce nabízí řešení v oblasti evidence jízd a spotřeby pohonných hmot pro malé a střední firmy disponující služebními vozy. Toto řešení je rozděleno do dvou samostatně funkčních celků - mobilní aplikace pro Windows Phone 7, která má zjednodušit zadávání nových jízd přímo v autě, a administračního rozhraní běžícím v prostředí Sharepoint, které umožní spravovat vozy, uživatele a zadané záznamy. Práce má teoreticko-praktický charakter. Úvodní část práce je věnovaná popisu problematiky a technologiím, na kterých je výsledná práce založena. Samostatná část je věnována relativně nové mobilní platformě Windows Phone 7. Podstatnou část diplomové práce tvoří mobilní aplikace, a proto je kladen důraz na návrh uživatelského rozhraní a použitelnost aplikace. Dále je představen Sharepoint, jako technologie rozšířená mezi firmami a celá infrastruktura navrženého řešení. Klíčová slova kniha jízd, mobilní aplikace, evidence vozidel, evidence jízd, evidence spotřeby, windows phone 7, sharepoint

10

Obsah Úvod

17

1 Windows Phone 7 aplikace 1.1 O platformě . . . . . . . . 1.2 Konkurence . . . . . . . . 1.3 Výhody WP7 . . . . . . . 1.4 Analýza a návrh . . . . . 1.5 Realizace . . . . . . . . . 1.6 Synchronizace se serverem 1.7 Testování . . . . . . . . . 1.8 Publikace aplikace . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

19 19 25 26 30 45 46 47 48

2 Administrační rozhraní 2.1 Úvod do Sharepoint . . . . . . 2.2 Microsoft Dynamics . . . . . . 2.3 Microsoft Project . . . . . . . . 2.4 Sharepoint a konkurenti . . . . 2.5 Analýza a návrh . . . . . . . . 2.6 Hermes framework . . . . . . . 2.7 Realizace . . . . . . . . . . . . 2.8 Synchronizace a webové služby 2.9 Testování . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

51 51 52 53 53 57 60 61 62 63

. . . . . . . .

. . . . . . . .

3 Další vývoj 65 3.1 Komunikační modul . . . . . . . . . . . . . . . . . . . . . . . . 65 3.2 Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4 Srovnání s konkurencí

69

Závěr

73

Literatura

75

A Seznam použitých zkratek

79 11

B Ukázka výsledné aplikace

81

C Obsah přiloženého CD

91

12

Seznam obrázků 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21 1.22 1.23 1.24 1.25 1.26 1.27 1.28 1.29 1.30

Metro dizajn na platformě Xbox a WP7 . . Různé typy klávesnice . . . . . . . . . . . . Typy menu v aplikaci . . . . . . . . . . . . Ukázka použití pivotu . . . . . . . . . . . . Ukázka použití panoramy . . . . . . . . . . Porovnání telefonů na platformách Android, Ukázka emulátoru . . . . . . . . . . . . . . Možnosti emulátoru . . . . . . . . . . . . . GUI: Diagram analytických tříd . . . . . . . UC: Možnosti aplikace . . . . . . . . . . . . UC: Automobil . . . . . . . . . . . . . . . . UC: Jízdy . . . . . . . . . . . . . . . . . . . UC: Tankování . . . . . . . . . . . . . . . . GUI: Navigační diagram pro WP7 aplikaci GUI: Úvodní obrazovka telefonu . . . . . . GUI: Stránka s výběrem auta . . . . . . . . GUI: Přidat auto . . . . . . . . . . . . . . . GUI: Informace o autě . . . . . . . . . . . . GUI: Výpis tankování . . . . . . . . . . . . GUI: Výpis jízd . . . . . . . . . . . . . . . . GUI: Editace auta - základní informace . . GUI: Editace auta - podrobnosti . . . . . . GUI: Přidat tankování . . . . . . . . . . . . GUI: Přidat jízdu . . . . . . . . . . . . . . . GUI: Detail jízdy . . . . . . . . . . . . . . . GUI: Detail jízdy - mapa . . . . . . . . . . GUI: Statistiky - průměrná spotřeba . . . . GUI: Nastavení aplikace . . . . . . . . . . . Komunikační diagram pro synchronizace . . Proces při schvalování aplikace . . . . . . .

. . . . . . . . . . . . . . . iOS, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . WP7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

20 21 22 24 24 26 28 28 31 32 33 34 35 37 38 38 39 40 41 41 42 42 43 43 43 43 44 44 47 49

2.1 2.2 2.3

Popis možností technologie Sharepoint . . . . . . . . . . . . . . . . Architektura IBM FileNet . . . . . . . . . . . . . . . . . . . . . . . Diagram struktury Oracle WebCenter . . . . . . . . . . . . . . . .

52 54 55 13

2.4 2.5 2.6

ERP řešení od NetSuite . . . . . . . . . . . . . . . . . . . . . . . . Ukázka SAP modulu . . . . . . . . . . . . . . . . . . . . . . . . . . Databázový model administračního rozhraní . . . . . . . . . . . . .

56 57 59

3.1

Základní deska modulu . . . . . . . . . . . . . . . . . . . . . . . .

66

4.1 4.2

Konkurence: AutoManager přehled . . . . . . . . . . . . . . . . . . Konkurence: AutoManager statistiky . . . . . . . . . . . . . . . . .

70 70

B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8

Aplikace WP7: Úvodní obrazovka . . . . . . . . . . . . . . . . . . Aplikace WP7: Přidání jízdy . . . . . . . . . . . . . . . . . . . . . Aplikace WP7: Výpis jízd . . . . . . . . . . . . . . . . . . . . . . . Aplikace WP7: Přidání nové lokace - výběr na mapě . . . . . . . . Aplikace WP7: Přidání tankování . . . . . . . . . . . . . . . . . . . Aplikace WP7: Výpis tankování . . . . . . . . . . . . . . . . . . . . Aplikace WP7: Ukázka formuláře pro export dat na SkyDrive . . . Administrace: Ukázka samostatného modulu, který může běžet v prostředí Sharepoint, nebo jako samostatná webová stránka. Není zde zobrazeno nasazení v Sharepoint, protože se liší intranet od intranetu dle firemní identity. . . . . . . . . . . . . . . . . . . . . . Administrace: Výpis jízd s možností filtrování podle každého sloupce. Zobrazení v prostředí Sharepoint. . . . . . . . . . . . . . . . . . . . Administrace: Formulář pro přidání jízdy . . . . . . . . . . . . . . Administrace: Zobrazení trasy na mapě . . . . . . . . . . . . . . . Administrace: Statistika vývoje spotřeby pro vybrané vozidlo . . .

81 81 82 82 83 83 84

B.9 B.10 B.11 B.12

14

85 86 87 88 89

Seznam tabulek C.1 Obsah přiloženého CD . . . . . . . . . . . . . . . . . . . . . . . . .

91

15

Úvod Kniha jízd, nebo evidence služebních jízd, je potřebná pro účely daňového přiznání, kterou musí každá fyzická osoba, či právnická osoba doložit, pokud má auto zapsané v majetku společnosti. Manuální vedení knihy jízd, tedy použití nějakého „excel“ souboru, je sice přehledné, ale nepraktické a častokrát i nepřesné. Problém je v tom, že každá jízda musí mít uveden počáteční a koncový stav počítadla kilometrů, jenže když řidič začne jízdu, tak tento „excel“ u sebe nemá a pak se jízdy zapisují dodatečně. Často se stává, že dané hodnoty se odhadují. V horším případě se jízda zapomene zaevidovat úplně. Dalším možným řešením je použití sešitu přimo v autě. Potom nás však čeká neustálé přepisování do informačního systému společnosti a do daňových přiznání. U všech těchto způsobů může dojít ke zkreslení výsledných údajů. Víme, že tyto problémy jsou spojené zejména s nedostupností knihy jízd v době, kdy ji člověk potřebuje nejvíce, tedy v autě. Naším cílem je usnadnit uživateli práci s knihou jízd a to v tom smyslu, že jí bude mít vždy po ruce - ve svém mobilním telefonu. Kromě samotné délky cesty je potřebné uvést i množství paliva, které se natankovalo/projezdilo na této cestě. Proto jsme se rozhodli umožnit uživateli přidávat jednotlivé záznamy o tankování a tímto způsobem sledovat spotřebu automobilu. Tuto funkcionalitu, kromě firem, samozřejmě využijí i běžní řidiči, kteří chtějí mít přehled o spotřebě svého vozu a výdajích s tím spojených. Výsledkem této diplomové práce bude aplikace pro mobilní telefon, která by měla v podstatě zjednodušit každodenně prováděné aktivity. Ze začátku jsme se rozhodli vyvíjet aplikaci pouze pro platformu Windows Phone 7. Co nás vedlo k této volbě se můžete dočíst v dalších částech této práce. Představme si, že pracujeme ve středně velké firmě a máme na starosti právě vedení knihy jízd u 20 automobilů. Pokud by měl každý řidič informace pouze ve svém mobilním zařízení, bylo by to pro nás velice nepraktické, protože bychom museli poprosit každého řidiče, aby nám tyto data z mobilní aplikace zpřístupnil. Z tohoto důvodu je součástí práce administrační rozhraní, které má poskytnout uživateli, ve většině případů správci, rozhraní pro správu řidičů, vozového parku, jednotlivých jízd, ale i spotřeby. Součástí administrace bude samozřejmě export dat a právě tato funkcionalita zjednoduší přiložení knihy jízd k daňovému přiznání - postačí jeden klik. Administrace 17

Úvod bude v podstatě samostatná webová aplikace, ale protože bude používána firmami, bude propojena s prostředím Sharepoint, které umožní integrovat již existující uživatelské účty s knihou jízd. Další nespornou výhodou je, že všechna data budou na jednom místě a uživatel nebude muset být zdlouhavě školen na nový systém. Motivací k napsání teto práce bylo vytvoření aplikace, která bude mít využití v reálném světe. Jejím cílem je usnadnění evidence služebních jízd pro potřeby daňového přiznání. Existuje mnoho aplikací evidujících spotřebu, nebo dokonce i samotné jízdy, ale žádná nenabízí komplexní řešení vhodné pro firmy. Většina aplikací se zaměřila pouze na jednu část (spotřeba, nebo jízdy) a další část podporuje omezeně, nebo vůbec. Dalším problémem je export dat z mobilního zařízení. Častokrát není umožněn, v takovém případě je aplikace nepoužitelná, protože zadaná data nejsou jednoduše k dispozici. Navíc v případě více řidičů a automobilů může být proces získávání dat nadlidským úkolem. Proto doufáme, že naše řešení odstraní výše zmíněné problémy a bude hojně využívané běžnými řidiči, ale najde si také cestu do malých, či středně velkých firem. Celá práce je formálně rozdělena do dvou velkých částí - mobilní aplikace a administrační rozhraní. Toto rozhodnutí bylo zvoleno z důvodu, že i když mobilní aplikace a administrační rozhraní spolu úzce souvisí a budou mezi sebou komunikovat, je potřebné ke každé aplikaci přistupovat jinak. V mobilní verzi se určitě zaměříme na uživatelské rozhraní, které musí být přehledné a jednoduše použitelné,aby ho mohli využívat uživatelé s rozdílnými zkušenostmi a zručnostmi v používání podobných aplikací. Proto bude kladen veliký důraz na to, aby se aplikace chovala tak, jak by uživatel očekával, tedy podobně jako aplikace, které pro danou mobilní platformu již zná a denně používá. Předpokládá se, že tato aplikace bude dostupná široké veřejnosti, tedy musí být použitelná bez nutnosti čtení zdlouhavého manuálu, či zaškolení. Naopak administrační rozhraní musí zejména zpřístupnit získané údaje a umožnit jejich správu. Bude se jednat o webovou aplikaci a s těmi mají uživatelé bohaté zkušenosti, tedy by je nemělo nic překvapit, co se týká uživatelského rozhraní. Toto rozhraní bude velice jednoduché. Navíc se při nasazení aplikace na Sharepoint v daném podniku, počítá s počátečním proškolením uživatelů, aby se se systémem seznámili a naučili s ním pracovat.

18

KAPITOLA

Windows Phone 7 aplikace 1.1

O platformě

Windows phone 7 (WP7) je mobilní operační systém vyvíjen firmou Microsoft, stejně jako jeho předchůdce, Windows Mobile. V porovnání s konkurencí, jako je iOS, Android, nebo symbian, je WP7 relativně mladá platforma [1]. Zásadním rozdílem mezi Windows Mobile a WP7 je cílová skupina, na kterou se Microsoft zaměřil. V minulosti to byli zaměstnanci firem a mobilní zařízení mělo fungovat jako přenosná kancelář, tedy byl kladen důraz na nástroje sady Office, email a jeho propojení se Sharepoint, možnost vzdálené plochy a pod. U nové platformy se však Microsoft vydal opačným směrem a rozhodl se oslovit co nejširší skupinu lidí. První verze Windows Phone 7 byla uvolněna koncem roku 2010 a i navzdory skepticizmu mnoha lidí, který panoval po předchozí verzi Windows Mobile, WP7 přesvědčila o svých kvalitách nejen širokou veřejnost, ale i odborníky. Svědčí o tom i cena za nejlepší mobilní platformu roku 2011 - Know Your Mobile Awards[2]. Porota ocenila zejména obrovský posun vpřed od Windows Mobile. Všechny překvapil také dizajn, který byl jednoduchý a účelný, ale hlavně Microsoft přišel s inovativním řešením a nesnažil se nikoho kopírovat. Na konferenci IDEA 2011 [3] získala platforma WP7 hned 4 ocenění - People’s choice, IDEA 2011 god award winner, Interaction award a best in show. Lze tedy říct, WP7 zde jasně dominoval. Microsoft nezaspal na vavřínech a to lze pozorovat i po uvedení dalši verze Windows Phone - 7.5 [4]. Každý uživatel mobilního zařizení s Windows Phone 7 si musí vytvořit Windows Live účet. Tento účet, podobně jako účet od Google, pod sebou zaštiťuje více služeb - Hotmail, Messenger, SkyDrive (úložiště dat), MSN a i Xbox Live účet. Tímto má uživatel všechny své údaje na jednom místě. Dále je te19

1

1. Windows Phone 7 aplikace lefonem schopen propojit Facebook a Google účty. Poté je možné v kalendáři zobrazit události z Facebooku, nebo kalendář z Google učtu.

1.1.1

Vzhled

Zásadním rozdílem mezi Windows Phone 7 a Windows Mobile, kterého si všimne opravdu každý, je dizajn. Ve WP7 se jmenuje Metro [5]. A protože měl Microsoft dostatek času a začal opravdu od znova, je dizajn zcela jiný. Microsoft chtěl vytvořit jednoduchý, účelný dizajn a inspiraci našel zejména v informačních tabulích na letišti a nádražích, které jsou jednoduché a čitelné. Při vývoji dizajnu se vývojové oddělení drželo několika zasad: • „light and simple“ - zobrazení jen důležitých informací, nezahltit uživatele zbytečnými detaily • „typography“ - použiti správné velikosti a typu písma • „motion“ - plynulé a jednoduché přechody mezi stránkami, animace prvků • „content not chrome“ - dizajn zaměřen na obsah, nezobrazovat zbytečná pozlátka • „honesty“ - přizpůsobení obsahu typu zařízení

Obrázek 1.1: Metro dizajn na platformě Xbox a WP7 Pro Metro jsou typické dlaždice s dominantními ikonami a jednobarevným pozadím. Tento trend je jasně vidět na obrázku 1.1. Po nasazení Metro dizajnu na Windows Phone 7 ho Microsoft koncem roku 2011 nasadil i na Xbox [6] a sjednotil tím dizajn svých platforem. 20

1.1. O platformě

1.1.2

Klávesnice

Na první pohled působí klávesnice velmi jednoduchým (obrázek 1.2), až minimalistickým dojmem, ostatně jako celý dizajn Windows Phone 7. K dispozici je několik druhů klávesnic, které lze v kódu nastavit. Typ klávesnice se odvíjí od vstupu, který chceme umožnit uživateli zadat. Na obrázku je vidět standardní (vlevo) a čiselná klávesnice (vpravo). Kromě těchto dvou typů existují i typy pro zadávání url, e-mailu, měny a pod.

Obrázek 1.2: Různé typy klávesnice Mohlo by se zdát, že se jedná pouze o klávesnici, tedy není potřeba nikterak bádat, aby byla použitelná, ovšem opak je pravdou. Dotyková obrazovka je malá, prsty někdy až moc široké a tak se jednoduše může vložit chybný znak. Aby Microsoft klávesnici vylepšil, použil techniku strojového učení a zapojil do výzkumu 4 odborníky, kteří měli na starost vyvinout „lepši dotykovou klávesnici“ [7]. Za pomocí experimentů se snažili zjistit, jak přesně se uživatelé trefují na jednotlivé klávesy, resp. jaká je šance, že zmáčknou správné písmeno. Zajímavostí je, že tyto údaje byly použity pro dynamickou velikost písmen. Na základě získaných údajů z experimentů a frekvenční jazykové analýzy se automaticky zvětšuje, nebo zmenšuje, plocha písmen a to podle pravděpodobnosti, že dané písmeno bude další v pořadí při psaní textu. Tedy pokud jsem již napsal „aut“ je veliká šance, že další písmeno bude „o“, a proto se velikost tlačítka změní. Ti z vás, kteří již Windows Phone použili, si jistě všimli, že na vzhledu klávesnice se tato funkčnost nijak neprojevuje. Ano, je to tak, vše se děje bez toho, aby o tom uživatel vůbec věděl. Přesnost predikce záleží od získaných dat. Někdy je algoritmus schopen předpovědět konkrétní jedno písmeno (jako v našem připadě se slovem „auto“), nebo skupinu písmen, případně jen říci, že následuje samohláska. V další verzi se do algoritmu promítne i rychlost psaní, protože i tento faktor ovlivňuje přesnost, jakou se 21

1. Windows Phone 7 aplikace uživatel trefuje na jednotlivá písmena. Kromě napsání samotného algoritmu je určitě výzvou i optimalizace algoritmu. Pokud si uvědomíme hardwarové omezení smartphonů, nároky na rychlost predikce, určitě se nejedná o lehký úkol. S podobnou tematikou přisla i hra TextTextRevolution [8], která vyhodnocuje uživatelovu rychlost a přesnost při psaní a na základě těchto údajů vytváří výsledkovou listinu. Jasný důkaz, že i „věda“ může být zábava.

1.1.3

Ovládací prvky

Při porovnání hardwarových tlačítek jednotlivých mobilních platforem bylo vidět, že pro zobrazení menu má Android vlastní tlačítko. U WP7 se toto řeší elegantně na úrovni aplikací. Na obrázku 1.3 jsou vidět možnosti zobrazení menu (v pořadí zleva doprava). Buď není vidět vůbec, nebo je minimalizované a uživatel ho může zvětšti (první zleva), připadně je vidět pouze ikona (druhé zleva), popotažení menu zobrazí popis ikony (třetí zleva), případně můžeme kromě ikon do menu přidat i jednotlivé položky, které se zobrazí právě popotažením menu (poslední na obrázku). Samozřejmě je možné menu nezobrazovat vůbec. V tomto ohledu je programátorovi ponechána volnost [9].

Obrázek 1.3: Typy menu v aplikaci Díky této koncepci bylo možné vypustit hardwarové tlačítko a díky tomu vzniklo vice místa pro 3 důležitá tlačítka - zpět, domů a hledat. Jak jste si určitě všimli, každá ikona je umístěna v kruhu. Toto není dizajn samotné aplikace, ale telefonu, resp. platformy. Zajímavé je, že toto orámování nijak nejde vypnout a když se na jedné konferenci Microsoftu někdo z publika zeptal, proč to tak je, nedokázali odpovědět, pouze, že se jim to „líbilo“. Při návrhu menu by měl mít programátor na paměti základní zásady: • důležité funkce by měli mít vlastní ikonu • používat srozumitelné ikonky/piktogramy, které uživatel pozná • položky v menu používat pro méně časté funkce, nebo pro funkce, které nelze popsat ikonou • používat systémové barvy pro ikony (ve většině případů černá a bíla) 22

1.1. O platformě • nepřidávat ikonu zpět, pokud naviguje zpět, stejně jako HW tlačítko Požadavky na ikony: • velikost ikony je 48x48 px • ikona se kreslí bez orámovaní - tedy kruhu • použit průhledné pozadí a bílou barvu ikony Programátor by si měl určitě dát pozor i na počet položek v menu. Rozhodně není vhodné zobrazit v menu více jak 5 položek, pak dochází k překrytí stránky a uživatel může být zmaten, s jakými daty vlastně pracuje. Pozor také na dlouhé názvy položek v menu. Stejné pravidlo platí i pro popisy ikon, které se automaticky ořezávají a zkrácený text určitě nepřidá na „user experience“.

1.1.4

Rozložení prvků na obrazovce

Pivot je nový ovládací prvek pro Windows Phone 7. Na první pohled je velice podobný běžnému uspořádaní s pomocí záložek (Tab Layout na Androidu, nebo Segment Control na iOS). Výhodou pivotu je, že na jedné stránce nabízí více informací. Uživateli stačí pouze posunutím zobrazit další obrazovku. Proto je Pivot vhodný pro filtrování, zobrazení dat různé povahy, průvodce při vyplňování formulářů a pod. Na WP7 zařízení narazíme na Pivot například při psaní zpráv nebo e-mailů. Každý Pivot může obsahovat více PivotItem, který představuje jednu obrazovku. Pohyby mezi obrazovkami jsou implementovány již v rámci pivotu, proto se o tuto funkčnost programátor nemusí zajímat. Není ani potřeba vytvářet navigaci, o všechno se stará Pivot, který v horní části vykresluje názvy jednotlivých PivotItem (obr. 1.4). Panorama je jedním ze zásadních prvků celého Metro UI, které Microsoft zavedl s příchodem WP7. Panorama se příliš neliší od pivotu, avšak jsou tu jisté zásadní rozdíly. Například panorama (obr 1.5) zobrazuje pouze 1 nadpis v horní části a to většinou uříznutý. Tímto se snaží v uživateli vzbudit dojem, že něco se „skrývá“ za okrajem a tím pádem uživatele přirozeně napadne posunout obrazovku na další. To je však jenom jeden ze způsobů. Dalším je zobrazení 80px výřezu z následující obrazovky v pravé části panoramy. Uživatelé WP7 se s tímto prvkem setkali například ve svých kontaktech. Vývojáře určitě napadne otázka výpočetního výkonu. Pivot i Panorama mají společné, že i když nejsou vidět všechny obrazovky, načítají se společně při prvním přístupu na stránku. Je to z toho důvodu, aby přechod mezi obrazovkami byl plynulý a u panoramy, aby se mohla zobrazit část další stránky. Proto by měli mít programátoři na paměti, že by mělo být obrazovek málo (doporučuje se max. 5) a měly by být jednoduché, aby se rychle načetli a uživatel zbytečně nečekal na načtení obsahu, který v dané chvíli nepotřebuje. 23

1. Windows Phone 7 aplikace

Obrázek 1.4: Ukázka použití pivotu

Obrázek 1.5: Ukázka použití panoramy

24

1.2. Konkurence

1.1.5

Témata

WP7 disponuje přibližně 10 barevnými tématy pro změnu dizajnu telefonu. Přepnutím tématu se změní i hlavní barva (např. pozadí dlaždic) a barva písma. Každé téma je k dispozici ve světlé ( „light“) a tmavé ( „dark“) verzi. Většina aplikací je naprogramována tak, aby respektovala uživatelské nastavení telefonu. Při vývoji aplikace je nutné brát v potaz různé možnosti nastavení a otestovat aplikaci pro „light“ i „dark“ verzi tématu, anebo barevné schéma v aplikaci nadefinovat samostatně.

1.2

Konkurence

Jak si vede Windows Phone 7 vůči konkurenci? Jak bylo zmíněno výše, je to ještě mladá platforma, a proto podíl na trhu není tak značný - v USA jsou to 2%, v Německu 7% (údaje z července 2011) [10]. Podle statistiky od T-Mobile z března 2012 [11] je podíl Windows Phone 7 na českém trhu 5%. Nejsilnějším hráčem na českém trhu smartphone je Symbian, tento trend je dán situací na trhu před několika lety. Android neexistoval, iPhone byl předražený a tak jediným řešením pro lidi, kteří chtěli smartphone byla koupě Nokie se Symbianem. Ze statistik, které poskytl T-Mobile je však jasné, že tento podíl prudce klesá a očekává se, že pokud Symbian nepříjde s převratnou novinkou, tak bude jeho podíl postupně klesat. Pravděpodobně na úkor Androidu a WP7. Důležitým krokem, který Microsoft udělal k prosazení Windows Phone 7 bylo navázání spolupráce se společností Nokia, která momentálně propaguje svou vlajkovou loď - Nokia Lumia 800. V současnosti je to asi nejlepší zařízení s WP7, které lze v ČR pořídit. Očekává se ještě uvedení Nokia Lumia 900 na český trh, avšak tato verze má poskytnout spíše kosmetické úpravy - větší displej, delší výdrž baterie a pod. I dizajn bude velice podobný. Na obrázku 1.6 můžeme vidět porovnání všech 3 platforem. Zleva to je Google Nexus S (Android), iPhone 4 od Apple (iOS) a úplně vpravo Nokia Lumioa 800 (WP7). Kromě odlišnosti v tvaru samotných telefonů určitě zaujme zejména spodní část s tlačítky. iPhone dominuje jedno hardwarové tlačítko, které slouží k navigaci. Funkcionalitu „zpět“ je nutné implementovat v každé aplikaci. Android má tlačitka 4 - zpět, menu, hledat a domů. Je tedy zjevné, že programátorům odpadá starost s implementací „zpět“ i tlačítka pro menu. Je však nutno podotknout, že jedno tlačítko u iPhone má přeci jenom výhodu - je uživatelsky přivětivé. Uživatel se nemusí starat o to, které tlačítko co dělá. Microsoft se rozhodl tyto dva přístupy zkombinovat a přišel s 3 tlačítky - zpět, domů a hledat. Za pomocí „zpět“ se lze vracet na předchozí obrazovky v telefonu stejně jako je uživatel zvyklý z internetového prohlížeče. Tlačítko domů uživatele přesměruje na úvodní obrazovku telefonu s výpisem aplikací. Hledat zobrazí v internetovém prohlížeči stránku Bing a je tedy možné okamžitě vyhledat potřebné informace. Poslední vlajková loď Androidu - Samsung Galaxy 25


Obrázek 1.6: Porovnání telefonů na platformách Android, iOS, WP7

Nexus [12] s Androidem 4.0 částečně kopíruje Microsoft. Má už jen 3 tlačítka - zpět, domů a menu. Hledat zde úplně chybí. Záleží asi na preferencích jednotlivých uživatelů, který způsob ovládání považují za víc intuitivní a příjemný. Ve prospěch iPhone mluví jednoduchost, na druhou stranu Windows Phone 7 získal několik ocenění od odborné veřejnosti.

1.3

Výhody WP7

Celkem zásadní otázkou je, co vede programátory k vývoji pro Windows Phone 7, když zastoupení této platformy na mobilním trhu je řádově v jednotkách procent. Odpověď je jednoduchá. .NET framework, potažmo C#, Silverlight a XNA mají obrovskou uživatelskou základnu a Microsoft právě spojil všechny tyto technologie a portoval je na mobilní zařízení. To znamená, že bez hlubšího bádání a učení se nového jazyka, jako je to například u iPhone (Objective C), může programátor využít stávajících technologií. Další výhodou je, že stále pracujeme ve známém prostředí - Visual Studio [13]. Existuje mnoho podpůrných nástrojů, jako je například Expression Blend [14], který umožňuje návrh GUI technikou „drag & drop“ bez nutnosti znát programovací jazyk, proto lze jednoduše oddělit práci grafika a programátora. Kromě rozvržení prvků na obrazovce umožňuje definovat i animace, nebo vlastní styly. Pokud má programátor k dispozici Expression Blend ve verzi Ultimate, je produkt 26

1.3. Výhody WP7 dodán i s rozšířením SketchFlow [15], které navíc umožňuje návrh „mockupů“. Tedy, v první fázi se může analytik oprostit od konkrétního grafického návrhu a může se soustředit pouze na návrh rozložení prvků, jaké informace se mají zobrazit a pod. Pokud by šlo pouze o „mockupy“ nejednalo by se o žádnou převratnou novinku pro WP7, takových programů je i pro ostatní platformy hodně - Balsamiq Mockups, Visio, iPhone Mockup [16]. SketchFlow však navíc umožňuje vytváření prototypů. To znamená, že po dokončení návrhu je možné aplikaci „proklikat“ v emulátoru pro WP7.

1.3.1

XNA a Silverlight

XNA framework určitě znají vývojáři pro Xbox nebo i PC, kteří měli tu možnost vyvíjet hry. Nyní se jim otvírá nové pole působnosti - mobilní hry. Nabízí se úplně jiný styl ovládaní, než u běžných her - multi-touch a akcelerometr. Samozřejmě se XNA framework pro mobilní zařízení mírně liší, ale i přesto mohou plně využít svých znalostí a zkušeností z vývoje her. Mnoho kritiků, zejména vývojářů her pro mobilní zařízení, vyčítá Microsoftu, že neumožnilo programátorům přístup k nativnímu kódu, který je tak žádán při optimalizaci her. Microsoft se ohání bezpečností, ale možná již v další verzi se dočkáme alespoň částečné podpory. Silverlight není pro .NET vývojáře žádnou novinkou. Již několik let je možné vyvíjet desktopové aplikace za pomoci WPF a právě WPF je základem pro WP7. Mobilní i desktopová verze Silverlight se od sebe moc neliší. Ale i tady lze najít jeden zásadní rozdíl - 2 elementy, které desktopová verze nenabízí a to - Panorama a Pivot, které jsou popsány o pár řádek výše.

1.3.2

Emulátor

Emulátor je bezpochyby silnou stránkou pro vývoj mobilních aplikací [17]. Jedná se vlastně o virtuální stroj, který má za úkol simulovat chování skutečného telefonu. Proto je možné v něm bez problému testovat vyvíjené aplikace a to bez obav, že by na mobilním zařízení výsledná aplikace nefungovala. Emulátor je navržen tak, aby se co nejvíce přiblížil mobilnímu zařízení a to kromě vzhledu i výkonem. Od telefonu se liší zejména tím, že je ovládán myší a ne dotykem, jak je to u fyzického zařízení. V emulátoru je možné spustit nejen samotnou aplikaci, ale je zde k dispozici i přístup k systému - prohlížeč, nastavení telefonu a pod (1.7). Emulátor rozhodně nemá za úkol úplně nahradit testování na zařízení, avšak určitě alespoň při počátečním testovaní ušetří čas a v neposlední řadě i finance a to zejména začínajícím programátorům, kterým odpadá nutnost koupě WP7 zařízení. Emulátor podporuje i rozhraní pro testování akcelerometru s možností nahrání sekvence hodnot. Takto je možné vytvořit testovací scénáře pro akcelerometr. Další podporovanou funkcí je GPS. V podružném okně emulátoru se zobrazí Bing mapy a jednoduchým kliknutím na mapu lze simulovat pozici 27


Obrázek 1.7: Ukázka emulátoru

Obrázek 1.8: Možnosti emulátoru

telefonu. Opět lze zaznamenat více souřadnic, uložit a poté přehrát. Obzvlášť při práci s GPS programátor ocení výhody emulátoru - odpadá mu nutnost běhat po městě s telefonem v ruce (obr. 1.8). Emulátor v současné verzi pro Windows Phone SDK 7.1 nepodporuje testování kompasu a tak pro tyto případy je nutné testovat přímo na telefonu. Dokonce pokud se neošetří, zda zařízení podporuje kompas, emulátor vyhodí výjimku a aplikace spadne. Snad se v další verzi dočkáme i podpory kompasu. K dispozici je i natáčení obrazovky, stejně jak tomu je u reálného zařízení a je tedy možné otestovat, jak se aplikace zachová. Při publikaci na marketplace určitě oceníme možnost vytvořit „screenshot“, tedy zachytit aktuální stav aplikace, který je potřebný připojit k popisu aplikace. 28

1.3. Výhody WP7

1.3.3

Mobilní zařízení

V oblasti mobilních zařízení se rozhodl Microsoft jít cestou někde mezi řešením od Apple (jeden HW) a Google (rozdílný HW). Proto se rozhodl specifikovat minimální požadavky na vybavení telefonu, ale i jeho vzhled. Toto rozhodnutí vzniklo z důvodu zabezpečit stejný „user experience“. Microsoft nechtěl dopustit, aby byla platforma degradovaná špatně zvoleným HW jen kvůli honbě za ziskem. Tento problém je vidět na telefonech s Androidem, zejména pohybujících se v nižších cenových relacích. Proto jsou zde minimální požadavky na procesor, paměť, podporované periferie a pod [18]. Každý telefon musí mít: • 3 HW tlačitka - zpět, domů a hledat • WVGA displej (800 x 480) • kapacitní displej podporující 4 dotyky současně • připojení k síti přes Wi-Fi i mobilní připojení • alespoň 256 MB RAM • A-GPS • alespoň 8GB úložiště pro data • akcelerometr Dále jsou zde volitelné funkce: • kompas • gyroskop • fotoaparát • přední fotoaparát Samozřejmě, zejména lidi, kteří jsou neradi něčím omezování, podotknou, že je to jen další forma šikany. Jenže podívejme se na Android z pohledu uživatele - jiný výkon zařízení, zdlouhavé čekání na aktualizace SW od výrobců, častokrát zastaralá verze SW. Ale také z pohledů programátorů - víc jak 10 různých rozlišení displeje, nejednotná podpora periferií - akcelerometr, kompas. Proto musí Microsoft diktovat výrobcům telefonů alespoň minimální požadavky a pak na oplátku může Microsoft zaručit, že nová aktualizace systému bude přímo od něj pro všechna zařízení ve stejný čas. 29


1.4

Analýza a návrh

Jak již bylo zmíněno v úvodu této práce cílem je vytvořit mobilní aplikaci pro platformu Windows Phone 7, která má umožnit evidenci služebních jízd a tankování. V této části se budeme věnovat problematice trochu podrobněji. Bude nastíněno řešení, které bude poté implementováno a popsáno v kapitole 1.5.

1.4.1

Funkční požadavky

• aplikace umožní spravovat vozidlo • aplikace umožní spravovat služební jízdy • aplikace umožní spravovat záznamy o tankování • automatický výpočet spotřeby dle tankování • statistika vývoje spotřeby

1.4.2

Nefunkční požadavky

• aplikace bude napsána v C# .NET • aplikace bude nasazena na mobilní zařízení Windows Phone 7. • pro ukládání dat bude použito IsolatedStorage v telefonu • aplikace bude komunikovat za pomoci REST služeb s administračním rozhraním • po přihlášení uživatele se provede synchronizace se serverem • po přidání nebo editaci záznamu (auto, jízda, tankování) se provede synchronizace se serverem

30

1.4. Analýza a návrh

Obrázek 1.9: GUI: Diagram analytických tříd

31

1. Windows Phone 7 aplikace Slovní popis analytických tříd • Car představuje třídu zastupující entitu auta se všemi potřebnými atributy dle zadání • FuelConsumption evidence spotřeby vozidla. Každé vozidlo má počáteční spotřebu (dle technického průkazu) a aktuální spotřebu (dle tankování) • User třída pro uchování základních údajů o uživateli • Trip reprezentuje jednu služební jízdu určenou počátečním a koncovým bodem - TripLocation • TripLocation počáteční nebo koncové místo služební cesty • FuelRecord záznam o tankování s možností definovat místo, kde bylo tankováno FuelLocation • FuelLocation lokace čerpací stanice

1.4.3

Případy užití

Na základě sepsaných požadavků byly vytvořeny a popsány případy užití (usecase, UC).

Obrázek 1.10: UC: Možnosti aplikace

32


Obrázek 1.11: UC: Automobil

Na obrázku 1.10 jsou vidět základní funkce aplikace. Uživatel bude mít možnost se přihlásit, odhlásit a změnit základní nastavení aplikace - zapnout/vypnout GPS, změnit jednotku vzdálenosti a objemu. Obrázek 1.11 zobrazuje akce, které může uživatel provést s autem. Má možnost CRUD operací (přidat, číst, změnit, smazat), zvolit aktuální auto a zobrazit jeho základní informace.

33


Obrázek 1.12: UC: Jízdy

Obrázek 1.12 popisuje CRUD operace pro jízdy. Uživatel může pro vybrané auto přidat služební jízdu. Dále má k dispozici přehled všech jízd s možností zobrazení detailu, úpravy jízdy nebo může zvolenou jízdu smazat.

34


Obrázek 1.13: UC: Tankování

Na obrázku 1.13 jsou CRUD operace pro tankování. Jednotlivé operace jsou podrobněji zobrazeny v sekci s návrhem uživatelského rozhraní. Z tohoto diagramu lze vyčíst podobné akce jako u jízd. Opět výpis, přidání, mazání, chybí zde pouze proklik na detail, který v případě tankování nemá smysl. Při prokliku na detail se rovnou zobrazí možnost editace.

35


1.4.4

Grafické uživatelské rozhraní

Návrh grafického uživatelského rozhraní (dále GUI) se odvíjel od analýzy případů užití. Byl to základní kámen, od kterého se postupně navrhli všechny stránky v aplikaci a rozkreslili jednotlivé obrazovky. Návrh GUI byl realizován za pomoci nástroje Microsoft Expression Blend [14] s rozšířením SketchFlow [15]. Tento nástroj avšak nepodporuje návrh přímo pro WP7, přesněji řečeno neobsahuje sadu prvků, které má v sobě mobilní zařízení. Tento problém vyřešilo open-source řešení SketchFlow Template for Windows Phone [19], které rozšiřuje SketchFlow právě o potřebné komponenty. Lze tedy jednoduše navrhnout vzhled jednotlivých stránek a poté za pomoci prototypů celý návrh otestovat. Jak je vidět na obrázků 1.15, SketFlow generuje komponenty v kresleném stylu, který vyvolává dojem ručního kreslení. Navigační diagram (obr. 1.14) zobrazuje možný pohyb uživatele mezi jednotlivými obrazovkami. V diagramu není zobrazeno, zda uživatel klikl na tlačítko, nebo byl na stránku automaticky přesměrován aplikací po nějaké akci. Je zde pouze zobrazeno, v jaké posloupnosti se mohou obrazovky zobrazovat. Každá stránka má textový popis a list akcí, které lze na dané stránce provést. Většinou se jedná o akce po kliknutí na položku v menu. Ikony, které budou ve finální aplikaci v dolním menu, jsou zde naznačeny kruhem s bílou výplní, nebo již s konkrétní ikonou. Pokud akce nemá naznačenou ikonu předpokládá se, že bude přidána jako položka vyjíždějícího menu.

36


Obrázek 1.14: GUI: Navigační diagram pro WP7 aplikaci

37


Obrázek 1.15: GUI: Úvodní obrazovka telefonu

Obrázek 1.16: GUI: Stránka s výběrem auta

Na obrázku 1.15 je zobrazena hlavní stránka mobilního zařízení. Je zde naznačen i prostor pro naši aplikaci - momentálně se nepočitá s „live tile“ ikonou, tedy zobrazením nějakých informací přímo v těle ikony. Další verze aplikace by už však mohla zobrazit aktuální průměrnou spotřebu, počet ujetých kilometrů nebo upozornění na blížící se servisní interval. Stránka na obr. 1.16 se uživateli zobrazí pokud bude chtít na stránce CarInfo (obr. 1.18) přepnout na přehled jiného vozidla. Pravděpodobně bude mít většina uživatelů pouze jedno auto, takže se o této stránce ani nedozví. Kliknutím na seznam vozidlo vybere jedno a svůj výběr potvrdí kliknutím na tlačítko v dolní části. Akce: • výběr vozidla a přesměrování na CarInfo

38


Obrázek 1.17: GUI: Přidat auto

Když uživatel poprvé spustí aplikaci, je automaticky přesměrován na stránku AddCarPage (obr. 1.17). Na této stránce vyplní základní informace o autě, které jsou potřebné pro práci s aplikací. Uživatel vyplní název vozidla, který má umožnit jednodušší identifikaci v případě více vozů. Uživateli bude umožněn výběr z nejběžnějších výrobců automobilů a tomu odpovídajících modelů. Dále bude uživatel dotázán na typ vozidla (osobní/nákladní), typ paliva (benzín/nafta/lpg, ...) a na závěr vyplní aktuální stav kilometrů. Kliknutím na tlačítko v dolním menu uloží zadané údaje a bude přesměrován na stránku CarInfo (obr. 1.18). Akce: • uložení vozidla a přesměrování na CarInfo

39


Obrázek 1.18: GUI: Informace o autě

Stránka CarInfo (obr. 1.18) má za úkol zobrazit základní informace o vozidle, které jsou pro uživatele důležité. Tato stránka se zobrazuje jako první, pokud uživatel již má v databázi telefonu uložené vozidlo. Zobrazují se údaje jako průměrná spotřeba, celková ujetá vzdálenost od přidání vozidla a celkový objem načerpaných pohonných hmot. Počítá se také s obrázkem vozidla. Buď z databáze vozidel, nebo by mohl mít uživatel možnost nahrát vlastní fotografii a tím si zde zobrazit své auto. Jedná se vlastně o Pivot 1.4, který dál pokračuje na obrazovkách Fuel (obr. 1.19) a Trip (obr. 1.20) Akce: • vybrání vozidla • přidání nového vozidla • editace vybraného vozidla • přesměrování na přihlašovací obrazovku • zobrazení statistik • smazaní auta

40


Obrázek 1.19: GUI: Výpis tankování

Obrázek 1.20: GUI: Výpis jízd

Jedná se o pokračování předchozího pivotu CarInfo (obr. 1.18) a zobrazuje se zde výpis všech záznamů o tankování (obr. 1.19). Záznamy jsou seřazeny od nejnovějšího po nejstarší a u každé položky jsou zobrazeny základní informace - datum tankování, název čerpací stanice, celková cena, množství pohonných hmot, cena za jednotku (litr nebo galon) a typ paliva (benzín/nafta/lpg, ...). Vedle každého záznamu bude zobrazeno tlačítko pro duplikování záznamu. Po kliknutí na duplikovat se vytvoří nový záznam s předvyplněnou cenou za jednotku a benzínovou stanicí. Je totiž předpoklad, že mezi jednotlivými tankováními se cena nebude výrazně lišit a částečně tedy zjednodušíme uživateli vyplňování formuláře. Akce: • přidání nového záznamu o tankování • smazání záznamu po „ tap & hold“ na konkrétní položce • duplikace záznamu Poslední část pivotu CarInfo (obr. 1.18). Zobrazuje se seznam provedených jízd (obr. 1.20) pro dané auto. Jsou zde zobrazeny pouze nejnutnější informace - datum od (kdy jízda začala), datum do (kdy jízda skončila), počáteční místo a koncové místo. Při zobrazení místa se zobrazí název, který uživatel vyplnil při jeho ukládání. Po kliknutí na záznam se zobrazí detail jízdy (obr. 1.25) Akce: • přidání nové jízdy • smazání záznamu po „ tap & hold“ na konkrétní položce • proklik na detail 41


Obrázek 1.21: GUI: Editace auta - základní informace

Obrázek 1.22: GUI: Editace auta - podrobnosti

Obrázky 1.21 a 1.22 představují dialog pro editaci údajů o automobilu. Formulář je za pomoci pivotu rozdělen na 2 části - základní údaje a více informaci. Stránka se základními údaji je totožná s formulářem pro přidání nového auta. V případě, že chce uživatel u svého auta evidovat i další údaje, stačí se posunout na druhou obrazovku a lze vyplnit informace jako SPZ, VIN, barva, výkon atd. Tyto informace jsou užitečné zejména při exportu knihy jízd v administraci, protože lze zobrazit další informace o autě, které ho blíže specifikují. Formulář je záměrně rozdělen na 2 části a to z toho důvodu, aby uživatel při prvotním zadávání auta do databáze nebyl zdržován v tu chvíli zbytečnými informacemi. Akce: • uložení změn • návrat na předchozí stránku

42


Obrázek 1.23: GUI: Přidat tankování

Obrázek 1.24: GUI: Přidat jízdu

Stránky 1.23 a 1.24 jsou si v podstatě podobné. Obě umožňují přidání nového záznamu, vyplňuje se zde datum, stav tachometru a vybírá se místo, ke kterému se záznam vztahuje. Při přidávání paliva se vždy podle 2 hodnot z množství paliva, celkové ceny a ceny za jednotku dopočítá třetí cena, aby uživatel nemusel vyplňovat všechny údaje a taky se může stát, že si prostě všechny informace již nepamatuje. Akce: • přidání nového záznamu

Obrázek 1.25: GUI: Detail jízdy

Obrázek 1.26: GUI: Detail jízdy - mapa 43

1. Windows Phone 7 aplikace Po kliku na jízdu na stránce 1.20 je uživatel přesměrován na detail 1.25. Zde se zobrazují všechny údaje vyplněné při přidávání jízdy a ještě k tomu se dopočítává ujetá vzdálenost - rozdíl mezi koncovým a počátečním stavem km. Detail mapy je opět pivot, jako je tomu v případě úvodní stránky. Skládá se ze 3 částí - výpis údajů, mapa a poznámky. Na obrazovce s mapou se zobrazí aktuální pozice, kde se uživatel nachází, startovní pozice a koncová pozice jízdy. Uživatel si tedy může na mapě prohlídnout svou trasu. Obrazovka s poznámkou zde není zobrazena. Jedná se pouze o textbox s možností přidání poznámky a tlačítko pro uložení ve spodní části obrazovky.

Obrázek 1.27: GUI: Statistiky - průměrná spotřeba

Obrázek 1.28: GUI: Nastavení aplikace

Stránka FuelStats 1.27 je jediná, která má povolené zobrazení i naležato, protože pouze u teto stránky, kde se zobrazuje graf, to má skutečně význam. Graf se natáhne na celou šířku telefonu a může tak zobrazit informace přehledněji. SettingsPage 1.28 zobrazuje seznam nastavení, které má uživatel k dispozici. Může nastavit jednotky, ve kterých chce zobrazovat a zadávat údaje a také povolit přístup k GPS pozici (toto nastavení je vyžadováno pro úspěšné nasazení na marketplace). Akce: • uložení nastavení

44

1.5. Realizace

1.5

Realizace

Vývoj aplikace se držel navrženého řešení z předchozí kapitoly 1.4. Samotný vývoj probíhal iterativním způsobem, kvůli možnosti testování jednotlivých modulů/funkčních celků a také kvůli tomu, že jsme se rozhodli, že vzniknou 2 verze aplikace. Tyto verze se v podstatě od sebe příliš neliší. „Lite“ verze neumožňuje komunikaci se serverem, tedy všechna data se ukládají do telefonu a neprobíhá zde žádná komunikace se serverem. „Full“ verze už podporuje komunikaci s administrační části a to oběma směry, tedy lze data získaná z telefonu pohodlně spravovat ve webovém prohlížeči. Jinak se mezi sebou tyto verze nijak neliší. Rozhodnutí padlo z důvodu umožnit používání aplikace i uživatelům, kteří chtějí aplikaci využívat bez Sharepointu. Tímto rozhodnutím se i trochu rozšířilo zadání a to konkrétně o možnost exportu dat z telefonu ve formátu CSV. Kvůli omezením platformy padlo rozhodnutí umožnit export na SkyDrive, který je k dispozici ke každému Windows Live účtu. Tímto účtem disponuje každý uživatel WP7, takže po provedení exportu se stačí přihlásit na SkyDrive a soubor stáhnout. Takto jsme umožnili alespoň nějakou zálohu dat i běžným uživatelům. Windows Phone 7 aplikace byla implementována za pomoci IDE Visual Studio 2010. Aplikace se vyvíjela pro Windows Phone 7.1. Výsledné řešení se skládá ze 6 vzájemně propojených projektů: • App - projekt s UI, komunikuje s BusinessLayer • BusinessLayer - logika aplikace, pracuje s databází (Database) a volá WS (ServiceClient) • Database - stará se o uložení údajů do IsolatedStorage. Implementovaná velice jednoduchá databáze • Localization - projekt obsahující všechny lokalizace. Pro každý jazyk se používá jeden soubor • ServiceClient - klient pro obsluhu webových služeb pro Bing mapy a pro komunikaci se serverovou částí aplikace • Toolkit - obsahuje sadu vyvinutých nástrojů - elementy pro uživatelský vstup, validace formulářů Struktura aplikace je dána rozdělením na jednotlivé projekty podle funkcionality, kterou poskytují. Je zde jednoznačné oddělení datové, byznys a prezentační vrstvy. Jedním z důvodu je přehlednost a čitelnost kódu, dalším důvodem je možnost jednoduchého rozšíření v budoucnu. V případě, že by se změnilo úložiště, nemusíme zasahovat do celé aplikace, ale stačí vyměnit pouze datovou vrstvu a aplikace bude nadále funkční, jak má. Další výhodou oddělení vrstev je možnost testování logiky aplikace bez nutnosti testovat přímo i GUI. 45


1.5.1

Použité knihovny

Kromě samostatně psaného kódu byly pro ulehčení vývoje použité i již existující knihovny. Největší pomoc poskytly knihovny od společnosti Telerik [20] přímo pro WP7. Jedná se o sadu základních formulářových prvků, které jsou však rozšířené o užitečné funkce, případně jsou zde zcela nové. V aplikaci je možné se s nimi setkat při zadávání data, času, nebo výběru ze seznamu položek. Pro komunikaci se SkyDrive se použila knihovna LIVE [21] přimo od Microsoftu, která poskytuje nativní C# API pro přihlášení na SkyDrive, nahrání a stažení souboru. Než vyšla tato knihovna bylo nutné složitě vytvářet dotazy na JS API přes webový prohlížeč v telefonu. Dalo by se tedy říct, že LIVE SDK podstatně zjednodušilo přístup na SkyDrive a díky tomu se začíná SkyDrive používat ve více aplikacích. Každá aplikace by měla umožnit logovat stav aplikace při chybě, nebo monitorovat její chování při používání uživatelem. Z tohoto důvodu byl použit nástroj Flurry [22], který poskytuje rozhraní pro analýzu mobilních aplikací. Stačí pár volání jejich SDK přímo v kódu aplikace a na webových stránkách Flurry se zobrazí přehledná statistika o používání aplikace - navštívené stránky, informace o zařízení. Kromě těchto údajů však poskytuje i mnohem zásadnější informace - log chyb. Je tedy možné zjistit, kolikrát aplikace „spadla“ a co to zapříčinilo. Nemusíme tedy spoléhat na oznámení chyb uživatelem. Dalo by se říci, že Flurry je takové Google Analytics pro mobilní aplikace.

1.6

Synchronizace se serverem

Součástí realizace je i synchronizace dat uložených v telefonu s daty na serveru. Synchronizace probíhá, pokud je vyplněna URL, na které se nachází webové služby, a pokud je k dispozici internetové připojení. První cyklus synchronizace se provádí po přihlášení uživatele a po spuštění aplikace. Při této příležitosti se nejdříve odešlou všechna data z telefonu na server. Odesílání dat probíhá v tomto pořadí: • data o vozidlech • uložená místa z jízd • samotné jízdy • čerpací stanice • tankování Po odeslání dat se zavolají webové služby pro získání aktuálních dat ze serveru. Každý záznam, který mobilní zařízení odešle, má přiřazeno na serveru 46

1.7. Testování vlastní ID. Toto ID se společně s ID z telefonu pošle zpět klientovi, aby mohl provést párování a při dalším volání metod mohl správně aktualizovat data. Po úspěšném zavolání metod se uloží „timestamp“ pro každou položku aktualizace. Tento časový údaj zabezpečí, že budeme na server posílat pouze nová data. Všechny změny týkající se vozidel, jízd a tankování jsou na serveru zaznamenány a v administraci jsou k dispozici k nahlédnutí. Uživatel se může kdykoli vrátit k předcházející verzi záznamu.

Obrázek 1.29: Komunikační diagram pro synchronizace Může se stát, že jedno auto je využíváno více řidiči. Proto u jednoho vozidla budou jízdy od různých řidičů, takže se v průběhu synchronizace dostanou do mobilu i „cizí“ data. Je to z toho důvodu, aby měl každý řidič přehled o používání auta. Samozřejmě, z důvodu jisté míry soukromí, jsou u cizích záznamů schované detaily. U jízdy to je důvod jízdy, poznámka a místo od a místo do. Uživatel tedy pouze uvidí, že byla vykonána jízda. Takový záznam není možné editovat, aby nedocházelo k přepisování dat jiným uživatelem. Při tankování se nezobrazí místo tankování. Při volání webové služby pro vozidla server vrátí všechna vozidla, na která má uživatel právo, a u kterých nastala nějaká změna od data poskytnutého mobilní aplikací. Místa služebních jízd a čerpací stanice se synchronizují všechny, není zde rozlišováno, který uživatel přidal danou lokaci, jsou tedy veřejné. Synchronizace dále probíhá při každé změně záznamu v telefonu, pokud je k dispozici připojení k internetu. Smazaný záznam se odešle hned po smazání v telefonu na server. Pokud nastane chyba, uloží se do seznamu ke smazání, který se odešle při nejbližší synchronizaci a záznam se na serveru označí jako smazán.

1.7 1.7.1

Testování White-box testy

Z důvodu charakteru aplikace byly „white-box“ testy, konkrétně unit testy, vynechány, protože by nepokryli nejdůležitější části programu - prokliky, zobrazení dat a pod. Samotná práce s daty je tak triviální, že časová investice 47

1. Windows Phone 7 aplikace do unit testování by byla větší, než přínos automatického testování. „Whitebox“ testy našli své uplatnění v druhé části implementovaného zadání a to konkrétně u webových služeb pro komunikaci mezi mobilní aplikací a administračním rozhraním.

1.7.2

Black-box testy

Tomuto typu testování byla věnována větší pozornost. Šlo zejména o to, aby se zabezpečilo, že aplikace po uživatelském vstupu nepřestane reagovat, nebo v horším případě, aby nespadla. Kromě testování samotným vývojářem byl k dispozici i další tester, který se nepodílel na samotné implementaci, takže měl k aplikaci kritičtější přístup. Při pokusu o alespoň částečnou automatizaci testování byl nalezen Expensify / WindowsPhoneTestFramework [23], který umožňuje provádět „blackbox“ testy automaticky. Ovládání je ale přes konzoly, případně unit testy ve Visual Studiu. Navíc vyžaduje naučit se sadu specifických příkazů pro konzoly, nebo testy. Zajímavé však je, že framework dokáže sám spustit emulátor, provést testy a poté vygenerovat html stránku s výsledky. Programátor zajisté ocení i „screenshot“ obrazovky z emulátoru, pokud test neproběhl v pořádku. Projekt bohužel nemá oficiální podporu, proto bychom ho nedoporučovali pro komerční projekty, alespoň ne v této fázi. Pokud by pro tento framework vzniklo IDE, více praktických ukázek, případně by kolem celého projektu vznikla početná komunita uživatelů ochotných pomoci, určitě by se pro něj našlo větší uplatnění. Zatím projekt zůstává jako zajímavý nápad pro nadšené programátory, kteří rádi zkouší nové věci. Bohužel, pro Windows Phone 7 neexistuje žádný ověřený nástroj, který by „black-box“ testování zjednodušil a automatizoval. Proto bylo nutné všechny tyto testy provádět manuálně. Kromě výše zmíněného testování byla aplikace prověřena i při samotné publikaci na Windows Phone Marketplace (viz 1.8).

1.8

Publikace aplikace

Před nasazením aplikace bylo potřeba vymyslet oficiální název, pod kterým se bude aplikace ve Windows Phone Marketplace zobrazovat. Po delších úvahách padlo rozhodnutí nazvat aplikaci BizCars. Je to jednoduché, krátké a vystihuje i podstatu aplikace. V první fázi byla aplikace nasazena na trhy anglicky mluvících zemí a také na český trh. Díky nastavení v aplikaci (přepínání mezi kilometry a mílemi, litry a galony) bylo umožněno používat aplikaci i v zemích, kde není zaveden metrický systém. Postupem času budou dodány další lokalizace a nic tedy nebude bránit tomu, aby se aplikace nasadila i na jiný marketplace. Určitě je pro uživatele výhodou, pokud má aplikaci k dispozici ve svém rodném jazyku. 48

1.8. Publikace aplikace Pro úspěšné nasazení na Windows Marketplace je potřeba splnit podmínky certifikace [24]. Určitě je dobré je pořádně nastudovat dříve, než se aplikace pošle ke schválení. Proces schválení trvá většinou 7 dnů a v případě zamítnutí a opětovného nasazení tato doba začíná zase od začátku. Řádné otestování aplikace před nasazením tedy může ušetřit týdny času. Aktualizace se snaží Microsoft vyřizovat dříve, většinou v průběhu 2-3 dnů. Na co si dát pozor: • nepodceňovat dizajn - je to první věc, kterou uživatel vidí a rozhoduje, jestli jí uživatel koupí, nebo ne • chování HW tlačítka zpět - pokud přepisujeme chování tohoto tlačítka, je potřeba tuto část řádně otestovat • výkon - pokud bude aplikace pomalá, uživatel ji záporně ohodnotí

Obrázek 1.30: Proces při schvalování aplikace V poslední době začal Microsoft důkladně kontrolovat přístup k periferiím telefonu, jako je například GPS. Pokud Vaše aplikace používá údaje z GPS, 49

1. Windows Phone 7 aplikace je potřeba, aby bylo v aplikaci jasně napsáno, k čemu budou GPS souřadnice použity a také je potřeba umožnit uživateli povolit, nebo zakázat používání GPS. Podobné pravidlo platí i pro běh aplikace na pozadí. V podstatě platí, že aplikace by měla o všech krocích informovat uživatele a umožnit mu tyto události kontrolovat [24].

50

KAPITOLA

Administrační rozhraní 2.1

Úvod do Sharepoint

Před popisem samotné analýzy a návrhu by se hodilo říci pár slov o Sharepointu, protože byl zvolen jako technologie, do které bude výsledná aplikace implementována. Takže co Sharepoint vlastně je a na co slouží? Sharepoint je vyvinutý společností Microsoft a jedná se o technologii na webovém základu. Vše tedy běží v prohlížeči a systém primárně slouží ke správě obsahu a dokumentů [25]. Jednoduše řečeno se systémem Sharepoint můžete vytvářet webové stránky a jednoduše sdílet informace s ostatními uživateli - například dokumenty. Co přesně Sharepoint dokáže zobrazuje Microsoft na svých stránkách za pomoci [26] tzv „Sharepoint wheel“. Obrázek popisuje základních 6 dovedností Sharepointu: • Sites - rozhraní pro správu webových stránek a sdílení dokumentů • Composites - poskytuje sadu nástrojů a komponent pro vytvoření vlastního řešení konkrétního problému • Insights - umožňuje zobrazení a přístup k datům z databází, reportů a aplikací • Communities - nabízí nástroje pro vzájemnou spolupráci a usnadňuje tak sdílení nových nápadů • Content - umožňuje nastavit pravidla pro správu obsahu a zpřístupnit ho uživatelům • Search - vyhledávání relevantních informací a kontaktů v systému 51

2

2. Administrační rozhraní

Obrázek 2.1: Popis možností technologie Sharepoint

Sharepoint se nejčastěji používá na intranetová, nebo internetová řešení. Samozřejmostí je podpora „content“ a „document management“, tedy správa obsahu a dokumentů - umožňuje sdílet informace mezi uživateli systému. Proč Sharepoint? Jedním z důvodů je široké zázemí .NET ve firmě Xperiensis [27]. Tato technologie je již léty prověřena, známe její výhody, ale i omezení. Z tohoto důvodu odpadá použití jiného jazyka než C#. Avšak hlavním důvodem, proč byl zvolen Sharepoint je pole jeho působnosti - malé a střední firmy. A naše řešení BizCars je cíleno právě na tuto skupinu. Sharepoint se tedy jasně nabízel. Sharepoint umožňuje ověřit uživatele na základě údaje zadaných při přihlášení do systému a zjednodušuje tím správu oprávnění v rámci Windows domény. Mnoho podniků má již jasně definovanou strukturu a pravomoci uživatelů v rámci počítačové sítě, tak proč těchto možností nevyužít. Chceme poskytnout komplexní řešení, které bude jednoduše integrovatelné do již existujícího systému ve firmách. Chceme toto řešení nabízet i firmám, které Sharepointem nedisponují. Zavedení samotného Sharepointu pouze kvůli BizCars by bylo zjevně neefektivní, proto jsme se rozhodli použít pro vývoj framework Hermes, který umožňuje nasazení i mimo Sharepoint, o tomto uvedeme více informací v části 2.5.

2.2

Microsoft Dynamics

Jedná se o byznys řešení pro firmy od společnosti Microsoft, které zahrnuje Customer Realtionship Management (CRM), Supply Chain Management a podporu finančního řízení. Microsoft koupil sadu nástrojů od různých firem, toto řešení zdokonalil a nejdříve ho prodával jako „Project Green“, až později 52

2.3. Microsoft Project byl projekt přejmenován na Dynamics. Je to ERP systém velice podobný řešení SAP, respektive nabízí podobné možnosti. Microsoft Dynamics se skláda ze 6 základních produktů: • Microsoft Dynamics AX • Microsoft Dynamics GP • Microsoft Dynamics NAV • Microsoft Dynamics SL • Microsoft Dynamics C5 Mezi výhody Microsoft Dynamics patří například více způsobů nasazení v závislosti na požadavcích firmy ( „on-demand“, „on-premise“, nebo kombinace obou. On-demand znamená, že je řešení nasazeno v „cloudu“ a on-premise je nasazení na firemní infrastrukturu. Microsoft Dynamics GP dokonce poskytuje až 62% veškeré funkcionality vyžadované firmami[28]. Žádný software neposkytne uživateli řešení na míru bez úprav nebo rozšíření, ale je důležité, aby uživateli nechyběli základní funkce pro podporu a fungování firmy. Microsoft Dynamics navíc integruje sadu nástrojů Office - Word, Excel, Outlook - a tím poskytuje uživateli podobné GUI jako zná z aplikací, které denně používá. Bezesporu největší výhodou Microsoft Dynamics je možnost propojení se sadou kancelářských nástrojů Office a intranetem Sharepoint. Nasazení a konfigurace je jednoduchá, navíc díky modulárnímu systému zákazník platí pouze za to, co opravdu potřebuje.

2.3

Microsoft Project

Jde o další produkt z dílen Microsoftu. Project je určen především na správu projektů, portfolia a vykazování. Hlavním důvodem, proč je zde zmíněn je fakt, že je součástí unifikovaného uživatelského rozhraní společně s MS Office, Dynamics a Sharepoint. Project je postaven na platformě Sharepoint, konkrétně nasazuje se na Sharepoint Server 2010. Dalo by se tedy říci, že se jedná o rozšíření funkcionality. Pro více informací o tomto produktu si lze přečíst podrobnou studii o výhodách a nevýhodách Microsoft Project od společnosti Core Consulting Group [29].

2.4

Sharepoint a konkurenti

V předcházející části 2.1 byly popsány výhody nasazení Sharepointu a jeho možné rozšíření v podobě Microsoft Dynamics a Microsoft Project. V této sekci se Vás pokusíme seznámit s konkurencí v rámci intranetových řešení. 53

2. Administrační rozhraní Po přečtení této části by mělo být zřejmé, proč jsme se rozhodli implementovat práci právě v prostředí Sharepoint. Jak již bylo zmíněno, zaměříme se na konkurenci poskytující intranetová řešení, protože „Sharepoint je intranet“. Hlavními konkurenty jsou řešení od IBM (FileNet [30]), Oracle (Portal [31]), NetSuite [32] a v neposlední řadě SAP [33]. Pár větami si zde uvedeme výhody a nevýhody jednotlivých řešení.

2.4.1

IBM FileNet Content Manager

Dle stránek výrobce [30] se jedná o systém na správu obsahu v enterprise prostředí. Přehledný úvod k této technologii nabízí Mid Sweden University ve svém článku [34]. Architektura je popsaná na obrázku 2.2. FileNet sdružuje 2 celky ECM (Enterprise Content Management) a BPM (Business Process Management). FileNet umožňuje především správu obsahu různého charakteru. Od webových stránek, až po dokumenty typu Word, Excel, PDF, obrázky a e-maily. V tomto je velice podobný prostředí Sharepoint. O tuto funkcionalitu se stará část ECM. BPM na druhé straně zabezpečuje byznys procesy jejich definování a kontrolu.

Obrázek 2.2: Architektura IBM FileNet K výhodám patří „event driven“ architektura, jasné definování procesů ve firmě, nahrazení dokumentů v papírové podobě, zálohování a sdílení obsahu. Těmito vlastnostmi by se vlastně dal charakterizovat libovolný „content management“ systém. Jako nevýhoda se jeví cena.

2.4.2

Oracle Portal

Jedná se o framework od společnosti Oracle v současnosti ve verzi 11 (rok 2012). Dle výrobce poskytuje prostředí pro vytváření, nasazení a správu portálů běžících na Oracle WebLogic Server. Portal nabízí zabezpečený přístup 54

2.4. Sharepoint a konkurenti k informacím, které je možno mezi uživateli jednoduše sdílet. Mezi hlavní výhody tohoto řešení asi patří skutečnost, že je to framework pro Javu. Oracle Portal vlastně spojuje jednotlivé moduly - portlety, které mohou být psané v Javě, ale protože je portlet vlastně XML, je možné ho psát i v jiném jazyku. Část funkcí Oracle Portal je psaná například v PL/SQL. Myšlenka „portálu“ je celkem zajímavá. Má programátorovi umožnit psát jednotlivé moduly kusy stránek - a poté je jednoduše spojit do jedné stránky. Moduly mohou být zabezpečeny centralizovaným bezpečnostním systémem, dotazovat se databázové vrstvy a pod. Samotné stránky potom nemusí vytvářet programátor, stačí zkušený uživatel.

Obrázek 2.3: Diagram struktury Oracle WebCenter

Seznam výhod je sepsán výše, teď je načase vyjmenovat i nevýhody. Z různých zdrojů (článků [35], [36], diskusí [37]) se člověk dozvídá pouze o nevýhodách. Mnoho programátorů je z tohoto řešení frustrovaných a už by se nikdy znovu dobrovolně nerozhodli pro Oracle Portal. Jeden z uživatelů se vyjádřil o Oracle Portal jako „PITA“, anglofonní čtenář si jistě domyslí význam. Z uvedených problémů lze vyjmenovat časté „patche“, které kromě opravy chyb, zavedou chyby nové. Programátoři dále uvádějí problémy se složitou konfigurací, chybové kódy Javy, špatná škálovatelnost a také podpora zaostává. Časté jsou i problémy s integrací vlastního zabezpečení, nebo údržbou speciální verze JVM od Oracle, která je požadována pro běh „portalu“. A jako perlička na závěr Oracle přesouvá svou pozornost od produktu Portal k novému, podobnému WebCenter[38]. To znamená, že si pravděpodobně i samotný Oracle uvědomil, že Portal je „mrtvý“ a zkouší přijít s alternativou. Doufejme, že se poučili z předchozích chyb. 55


2.4.3

NetSuite

Jedná se o další ERP, CRM, e-commerce řešení [32], tentokrát běžící v „cloudu“. Své zákazníky si získalo právě díky této funkcionalitě, která snižuje náklady na provoz IT. NetSuite je tedy webové řešení, které postačí běžným požadavkům firem. Problém nastává, pokud firma roste nebo chce upravit stávající řešení. NetSuite má totiž vážné problémy s flexibilitou a o své zákazníky z tohoto důvodu často přichází. Ti pak přejdou ke konkurenci například v podobě Sharepoint. Přechod však není tak jednoduchý. Všechna Vaše data jsou uložena v „cloudu“ NetSuite a dostat je „ven“ v rozumném formátu a bez většího úsilí je téměř nemožné.

Obrázek 2.4: ERP řešení od NetSuite Kromě zmiňovaných nedostatků NetSuite stahuje k zemi i skutečnost, že nabízí pouze webové řešení, které jak již bylo uvedeno výše, běží pouze v „cloudu“, a proto nemusí být vhodné pro všechny zákazníky, zejména pro ty, kteří neradi poskytují svá citlivá data třetím stranám.

2.4.4

SAP

SAP patří mezi jedno z nejznámějších podnikových, nejen intranetových, řešení [33]. Vyznačuje se zejména svou modularitou, tedy výsledný systém, nasazený u zákazníka, tvoří jádro SAPu a moduly dle jeho potřeb. SAP je typický svými hotovými řešeními pro jednotlivá firemní odvětví. Od zákazníka tedy není vyžadována hlubší znalost problematiky, ale SAP přichází s již ověřeným řešením z daného segmentu, která získal od stávajících zákazníků. V případě potřeb je možné toto řešení upravit, avšak je potřeba si uvědomit, že tento úkon předražuje již celkem nákladné řešení ve formě SAPu. Navíc existuje pouze pár specialistů, kteří se opravdu v této technologii vyznají, to znamená, že kromě instalace modulů jsou schopni vytvářet nové konfigurace. Správné nastavení SAPu není jednoduché, proto si za to tito odborníci nechávají dobře zaplatit. 56


Obrázek 2.5: Ukázka SAP modulu

Na obrázku 2.5 je vidět ukázka SAP modulu[39]. Význam jednotlivých zkratek: QM - Quality Management, PM - Plant Maintenance, HR - Human Resources, IS - Industry Solutions, WF - Business Workflow, PS - Project Systems, FI - Financial Accounting, CO - Controlling, AM - Asset Management, PP - Production Planning, MM - Materials Management, SD - Sales and Distribution SAP je vhodné řešení například pro logistická centra, sklady, výrobní závody a podobné podniky. Nasazovat ho do malé, nebo střední firmy, pouze jako „content management“ je neefektivní, nejen z hlediska financí, ale i z pohledu odladění systému a i tak to velmi připomíná „jít na vrabce kanónem“. Z popisu SAPu by se mohlo zdát, že v tomto segmentu pro něj není Sharepoint konkurence. Avšak po integraci pomocných nástrojů (modulů) do Sharepointu se síly vyrovnávají. Jedná se zejména o Microsoft Dynamics [40] a Microsoft Project [41]. Po doinstalování těchto rozšíření se síly vyrovnávají a SAP i Sharepoint poskytují stejně kvalitní a komplexní řešení.

2.5

Analýza a návrh

Při analýze řešení a následném návrhu jsme vycházeli z požadavků a funkcí mobilní aplikace. Tyto informace se osvědčily jako vhodný základ pro další analýzu. Níže jsou vypsány funkční i nefunkční požadavky. Některé se kryjí s požadavky na mobilní aplikace, avšak jsou zde vypsány znovu, aby nebylo třeba všechny požadavky složitě dohledávat v dokumentu.

2.5.1

Funkční požadavky

• aplikace umožní spravovat vozidlo • aplikace umožní spravovat služební jízdy 57

2. Administrační rozhraní • aplikace umožní spravovat záznamy o tankování • automatický výpočet spotřeby dle tankování • aplikace umožní spravovat uživatelské účty • aplikace bude komunikovat s mobilním zařízením za pomoci webových služeb • změny se budou logovat • statistika vývoje spotřeby

2.5.2

Nefunkční požadavky

• aplikace bude napsána v C# .NET • aplikace bude běžet v prostředí Sharepoint • použije se WCF pro webové služby • aplikace bude komunikovat za pomoci REST služeb s mobilním zařízením • aplikace použije framework Hermes pro implementaci

2.5.3

Databázový model

V analýze se nebudeme věnovat entitám, které slouží jako výčet prvků (Model, Manufacturer, CarType, FuelType, Currency) a místo toho se soustředíme na stavební kameny databázového návrhu. Než samotné atributy jednotlivých tabulek jsou více zajímavé relace mezi nimi. Mezi základní tabulky návrhu patří User, která má za úkol evidovat seznam uživatelů používajících naší aplikaci. Tato tabulka je propojena s tabulkou Session, která má za úkol evidovat přihlášené uživatele z mobilního zařízení. Každý uživatel může vlastnit žádné nebo více aut (relace User a Car) a s těmito auty může podniknout služební cestu (relace Car - User, User - Trip) nebo zaznamenat tankování (relace Car - User, User - FuelRecord). Jak je vidět z obrázku 2.6, základní entity knihy jízd jsou „jištěny“ jistou formou logování ve stylu duplikace aktuálních dat do jiné tabulky s označením „log“. Týká se to entit Car, Trip a FuelRecord. Je to z toho důvodu, že tyto entity jsou součástí synchronizace s mobilním zařízením a nemůžeme dopustit, aby kvůli jakémukoliv problému v procesu synchronizace uživatelé přišli o vložená data. Mohlo by to totiž uživatele odradit od používání systému a v konečném důsledku by to znamenalo i finanční ztrátu. I z tohoto důvodu se záznamy z databáze nemažou, ale pouze se nastaví flag „deleted“ na true. Tím pádem je možné v aplikaci nahlížet i na smazané záznamy a uživatel může tento krok vrátit zpět. 58


Obrázek 2.6: Databázový model administračního rozhraní

2.5.4

Grafické uživatelské rozhraní a případy užití

Na rozdíl od analýzy pro Windows Phone 7 (1.4) zde není popsáno grafické uživatelské rozhraní a případy užití. S ohledem na charakter administračního rozhraní by bylo zbytečné zdlouhavě popisovat rozvržení prvků na stránce, když se jedná o webovou aplikaci, která svým uspořádáním nemá poskytnout nic revolučního. To stejné platí i pro případy užití. Jsou velice podobné těm z mobilní aplikace a proto bylo rozhodnuto, že místo vložení všech diagramů do samotné diplomové práce, budou tyto k dispozici na přiloženém CD, kde si je čtenár může prohlédnout. 59


2.5.5

Mapy

Aplikace využívá mapy pro zadání začátku, konce jízdy a také čerpací stanice. Mapa se také použivá pro zobrazení průběhu uskutečněné jízdy. V zadaní diplomové práce bylo specifikováno, že se má použít Google Maps pro mapové podklady. Nakonec však padlo rozhodnutí použít Bing Maps, protože tyto mapy jsou již použity na Windows Phone 7 klientovi. API je již tedy nastudované a dá se znovu použít i část kódu zabezpečující jeho volání i zpracování odpovědi. Bing mapy v některých funkcích zaostávají za Google mapami, avšak stále se snaží zlepšit jak mapové podklady, tak i vyhledávání.

2.6

Hermes framework

Jedná se o sadu knihoven vyvíjenou společností Xperiensis[27]. Cílem bylo vyvinout prostředí, které by zjednodušilo integraci do intranetového a internetového prostředí Sharepoint[42]. Jeho hlavní výhodou je zpřístupnění komponent pro ověřování práv, logování a automatická autorizace uživatele při přístupu na stránku. Další výhodou tohoto frameworku je možnost pracovat jak v prostředí Sharepoint, tak i jako běžná ASP.NET stránka. Tím je usnadněna případná migrace z jednoho řešení na druhé a programátor není zatěžován specifiky při vývoji pro jednu, či druhou variantu. Hlavní výhodou použití tohoto frameworku je sjednocení a zjednodušení práce s bezpečností a a logováním. Hermes poskytuje komponenty pro logování (LogProvider), cachování (CacheProvider), audit (AuditProvider) a zajišťuje bezpečnost (SecurityProvider). Komponenta pro logování poskytuje 4 úrovně logování, podle závažnosti zprávy/chyby - debug, info, warning a error. V případě potřeby je možné vytvořit vlastní mechanismus logování implementací rozhraní ILogProvider. Podobný princip se dá uplatnit pro cachovaní (ICacheProvider), audit (IAuditProvider) a bezpečnost (ISecurityProvider).

2.6.1

Ověřování práv

V aplikacích používajících Hermes framework probíhá ověřování uživatelských práv na úrovni každého usecase. Většinou se usecasem rozumí stránka, v některých případech pouze funkční část. Uživatelská práva se definují v podobě XML dokumentu, podle kterého se pak ověřuje, zda uživatel má právo na zobrazení stránky. V případě, že chceme větší kontrolu nad právy v rámci jednoho usecase (například editace, mazání záznamu) stačí založit fiktivní usecase v XML a poté zavolat IsUsecaseAuthorize. Uživatel je ověřen na základě uživatelského jména v systému Windows, případně údajů zadaných v přihlašovacím formuláři. Protože Hermes framework není veřejně dostupný, nemá smysl popisovat postup pro jeho implementaci do projektu, nebo uvádět praktické ukázky. 60

2.7. Realizace Místo toho zde byly sepsány výhody a důvody pro použití tohoto frameworku, který se stal stavebním kamenem administračního rozhraní.

2.6.2

Inversion of Control a Dependency Injection

Inversion of Control - IoC, je návrhový vzor, který uvolňuje vztahy mezi jinak pevně svázanými komponentami [43]. Jednoduše řečeno, třída nevytváří instance ostatních tříd, ale jsou jí nějak zvenčí dodány. Tímto způsobem je právě uvolněna jinak těsná vazba a umožňuje se definovat vztahy mezi třídami „za běhu“. Existují 3 způsoby jakým se realizuje tento návrhový vzor: • Constructor Injection - do třídy vnoříme instance ostatních tříd za pomoci parametrů v konstruktoru • Setter Injection - třída má definované settery a za jejich pomoci se definují použité instance (používá například Spring Framework) • Interface Injection - rozhraní definuje metody potřebné pro nastavování instancí objektů Pro sestavení struktury se využívá IoC kontejneru. Podobným návrhovým vzorem je Dependency Injection - DI. Dalo by se říci, že se jedná o novější verzi IoC. Výhody: • jednodušší testování na sobě téměř nezávislých částí • znovupoužitelnost - IoC kontejner většinou nevyžaduje zásah do kódu aplikace Nevýhody: • nevhodné pro jednodušší aplikace • pro programátora neznalého IoC může být složitější vyznat se v kódu Dependency Injection bylo použito při návrhu Hermes frameworku. Z toho vyplývá jedna zásadní výhoda - části frameworku se dají jednoduše přepsat a pokud budou implementovat správné rozhraní, lze nimi nahradit původní funkcionalitu pouze změnou v konfiguračním souboru.

2.7

Realizace

Vnitřní struktura aplikace byla rozdělena do několika projektů: • BRO - část projektu, která má na starosti práci s databází a „bussiness“ objekty využívající Hermes framework 61

2. Administrační rozhraní • UI - prezentační vrstva projektu napsána za pomoci Hermes frameworku • ServiceRole - WCF projekt poskytující REST rozhraní pro webové služby Všechny tabulky z analýzy 2.5.3 mají v projektu BRO korespondující byznys třídy. Pro výčtové tabulky (Model, Manufacturer, CarType, FuelType, Currency) je použito XML dokumentů, které mají za úkol definovat počáteční obsah těchto tabulek. V administraci není možné tyto záznamy momentálně editovat. XML soubory byli zvoleny z důvodu jednoduchého nasazení do mobilní aplikace, čímž se zaručí konzistence mezi WP7 a administrací. V průběhu analýzy se jasně definovali technologie, které bude administrační rozhraní používat a v jakém prostředí poběží. Za zmínku určitě stojí popsat framework Hermes, který určitě nepatří mezi běžně dostupné frameworky.

2.8

Synchronizace a webové služby

V diplomové práci je již popsána synchronizace ze strany mobilní aplikace, tato část se věnuje popisu z pohledu serveru a webových služeb. Synchronizace probíhá na vyžádání ze strany klienta, jak je popsáno v části 1.6. Server zpracovává data přijaté webovou službou. Každý záznam obsahuje „Datetime“, který určuje stáří záznamu. Čas se posílá ve formátu UTC, na serveru se porovná se záznamem se stejným ID a pokud je časový záznam z klienta novější, přidá se do databáze jako aktuální, jinak se pouze uloží do logu, který je zobrazen v administraci. Při požadavku o data od klienta server přijme opět časový údaj, který symbolizuje poslední čas synchronizace, a podle tohoto server vybere z databáze pouze novější údaje. Cílem je minimalizovat datový přenos, který zatěžuje zejména mobilní zařízení. Seznam webových služeb typu GET: • version - aktuální verze webových služeb • me - zobrazení informací o uživateli • trips - seznam služebních jízd • triplocations - seznam míst služebních jízd • fuelrecords - seznam tankování • fuellocations - seznam čerpacích stanic

62

2.9. Testování Seznam webových služeb typu POST: • login - přihlášení uživatele • logout - odhlášení uživatele • trips - odeslání seznamu jízd na server • triplocations - odeslání seznamu míst služebních jízd na server • fuelrecords - odeslání seznamu tankování na server • fuellocations - odeslání seznamu čerpacích stanic na server

2.9

Testování

Testování administračního rozhraní bylo zaměřeno zejména na unit testy webových služeb. Bylo nutné právě tuto funkcionalitu podrobně otestovat a zaručit, že bude fungovat. Jako hlavní výhodou se ukázala možnost jednoduše ověřit, že webové služby fungují jak mají, i po zásahu do kódu při rozšíření funkcionalit, nebo při refacktoringu. Pro tento styl testování byla použita knihona NUnit[44] určena přimo pro .NET. Samozřejmě byla aplikace testována i jinými postupy (testování UI, unit testy pro třídy, atd.), avšak ty jsou tak triviální a běžnou záležitostí, že nemá smysl se o nich rozepisovat.

2.9.1

Fiddler

Pro testování funkčnosti poskytovatele webových služeb a služeb samotných byl použit nástroj Fiddler[45]. Jedná se o program, který zaznamenává veškerou komunikaci probíhající na http/https a přehledně ji zobrazuje uživateli. Kromě monitorování lze požadavky i vytvářet. Lze volit mezi požadavky typu GET, POST a PUT. Ke každému požadavku lze kromě URL specifikovat i obsah zprávy a Fiddler poté zobrazí odpověď, která mu z dané URL přišla. Pro počáteční testování nastavení serveru a jednoduchých webových služeb se Fiddler jevil jako skvělý nástroj. Avšak z důvodu potřeby automatizování testů byly později vytvořeny unit testy, které lze jednoduše a opakovaně spouštět.

63

KAPITOLA

Další vývoj Jako u každé aplikace, tak i při vývoji BizCars se myslelo na možná vylepšení a další vývoj. Dlouho jsme přemýšleli i o způsobu, jak uživatele donutit zadat tankování a služební jízdu přímo v autě, upozornit ho, že teď je ten správný čas. Povolením běhu aplikace na pozadí telefonu by se dala zjišťovat GPS poloha uživatele a pokud by se výrazně měnila (rychlost změny polohy by byla větší než při chůzi), byl by uživatel upozorněn, jestli nechce danou trasu přidat jako služební jízdu.

3.1

Komunikační modul

Zaznamenání tankování bychom rádi prováděli instalací speciálního modulu přímo do vozidla. Tento modul by byl připojen k SW auta přes OBD II konektor, který je běžný pro většinu automobilek a umožňuje získávat aktuální data. Bylo by tedy možné monitorovat stav paliva a pokud by zde byl zaznamenán nárůst, bylo by možné ihned zjistit množství paliva, spojit se s mobilním telefonem, zaznamenat tankování a upozornit na tuto událost uživatele. Podobným způsobem by se dal monitorovat stav kilometrů při nastartování vozidla a stav kilometrů při jeho vypnutí. Zaznamenáním času a GPS souřadnice z telefonu bychom získali všechna data potřebná pro automatické uložení služební jízdy. Pro konstrukci modulu by se dalo použít řešení od firmy GHI electronics[46], která nabízí jednotlivé HW díly s podporou .NET frameworku. Dala by se použít základní deska FEZ Cerberus Mainboard[47], která podporuje .NET a má rozhraní pro 8 volitelných modulů. Základní desku by bylo potřebné rozšířit o OBD II modul[48] a bluetooth modul[49] pro komunikaci s mobilním telefonem. Poté by zbylo už „jen“ jednotku naprogramovat a odladit v reálném provozu. Výzvou by bylo nejen samotné programování s omezeným množstvím paměti, nebo rychlosti procesoru, ale také vytvoření testovacího 65

3

3. Další vývoj prostředí, které by simulovalo použití v autě. Z pochopitelných důvodů by nebylo možné všechny testy provádět přímo ve vozidle.

Obrázek 3.1: Základní deska modulu Cena tohoto řešení pouze za materiál by byla 130 dolarů. A to ještě pořád zbývá vyřešit napájení, vhodné umístění ve vozidle a naprogramování jednotky. Vývoj takového modulu by byl časově i finančně náročný, ale určitě zajímavý nejen pro vývojáře, ale i pro trh. V současnosti je na trhu zájem o jednotky monitorující polohu vozidla a vedení knihy jízd zejména ze strany firem disponujících větším množstvím automobilů, které je složité osobně ohlídat.

3.2

Cloud

Při návrhu a vývoji bylo myšleno i na možnosti rozšíření administračního rozhraní a to konkrétně nasazením na cloud. Pro naši aplikaci připadá v úvahu řešení od Microsoftu - Windows Azure[50]. Pokud bychom chtěli uskutečnit tento nápad, stačilo by upravit databázovou vrstvu tak, aby využívala databázi Windows Azure. Tato migrace by neměla být složitá, protože stávající řešení používá MSSQL, které běží i na Windows Azure. Hlavní výhodou tohoto řešení by bylo, že zákazníkům by odpadla nutnost vlastnit HW infrastrukturu 66

3.2. Cloud a tím by se snížili i náklady na údržbu. Služba by byla dostupná odkudkoli, nezávisle na Sharepointu. Dokonce by se dala služba jednoduše zpřístupnit bezplatně veřejnosti, alespoň v základní verzi, a tím by mohli naplno vyzkoušet řešení BizCars a v připadě zájmu by pak mohli zakoupit licenci na plnou verzi.

67

KAPITOLA

Srovnání s konkurencí Pro mobilní aplikaci existuje široká konkurence, většina však nabízí pouze evidenci spotřeby, některé evidenci nákladu a v ideálním případě spojují obě funkce dohromady. Většina aplikací však není dotažených do konce, jedná se spíše o pokusné projekty, nebo projekty vytvořené pro jednotlivce. Tento pocit uživatel získá jak z dizajnu, tak i občasných chyb nebo rozložení prvků. Aplikace se nezaměřují na použitelnost, nezjednodušují uživateli rutinní práci. Na rozdíl od aplikace AutoManger[51], která zmíněné neduhy minimalizuje, nebo dokonce úplně odstraňuje. Poskytuje podobnou funkcionalitu, jako naše řešení BizCars. AutoManageru chybí evidence služebních jízd, ale navíc nabízí rozhraní pro evidenci nákladů spojených s provozem vozidla. Nabízí export na SkyDrive (stejně jako naše řešení), ale zároveň i import dat ze SkyDrive, tedy lze jednoduše přenášet informace mezi telefony. Tuto funkcionalitu se snažilo BizCars nahradit komunikací se serverem. AutoManager nemá webové administrační rozhraní, ani jinou možnost správy údajů, než v telefonu. Na druhou stranu má řešení pro všechny 3 platformy (WP7, Android, iOS). Pokud chceme být úspěšní s našim produktem, musíme rozhodně dát pozor na nové verze AutoManageru a snažit se co nejdříve smazat rozdíl, který momentálně, v některých oblastech, hraje ve prospěch konkurence. Naše aplikace sice neběží na všech platformách, ale díky použití REST pro komunikaci se serverem by neměl být problém doprogramovat klienty i pro další mobilní zařízení. Momentálně to však není prioritou a snažíme se zaměřit na poskytnutí komplexního řešení pro evidenci jízd. Po porovnání mobilních aplikací je na čase porovnat i desktopová, nebo webová řešení. Pokud se zaměříme na český trh, je zde hned několik produktů, které nabízejí širokou škálu funkcí. Patři sem například Autopark[52] a Autoplan[53]. Kromě funkcí, které jsou implementované v našem řešení, 69

4

4. Srovnání s konkurencí

Obrázek 4.1: Konkurence: AutoManager přehled

Obrázek 4.2: Konkurence: AutoManager statistiky

nabízí například i cestovní příkazy, vyřazení auta z evidence na určitou dobu, evidenci platebních karet nebo uzamknout záznamy za určité období. Například Autopark umožňuje rekonstruovat knihu jízd za minulé roky podle určených tras a četnosti jízd. Program dále dopočítává domácí, i zahraniční stravné. Celkově je více propojen s legislativou České republiky. Autoplan automaticky počítá spotřebu vozidla dle čerpaných pohonných hmot a pak ji porovnává se spotřebou zadanou dle technického průkazu. Pak je možné administrátora automaticky upozornit na zvýšenou spotřebu u některých řidičů. Kromě evidence služebních vozidel nabízí i vedení jízd pro soukromé vozidlo, u kterého automaticky vypočítá výši náhrad. Všechny již zmíněné funkce konkurence jsou užitečné, které umožňují komplexní evidenci aut, jízd a celé administrativy kolem, avšak neumožní uživateli zadat jízdu, nebo tankování přímo z auta, tedy tam, kde je to žádoucí. Pokud řidič nezadá potřebné údaje přímo ve vozidle, častokrát na to zapomene, nebo pak u svého počítače zadá zkreslené údaje. Proto naší hlavní výhodou je zadávání jízd a tankování přímo ve vozidle prostřednictvím telefonu. Díky použití frameworku Hermes můžeme administrační rozhraní nasadit samostatně, nebo implementovat do prostředí Sharepoint, a to nám bezesporu poskytuje konkurenční výhodu. Pro uživatele je příjemnější používat jeden sys70

tém, který je navíc dostupný prostřednictvím internetu z libovolného místa, než na každý úkon použít jinou aplikaci. I z pohledu firmy je jednodušší spravovat jeden systém. Z porovnání s konkurenci vyplynulo, že zejména v administračním rozhraní zaostáváme. Je potřeba, kromě samotné evidence jízd, také umožnit rekonstrukci jízd, automatické propočty a další funkcionalitu. Jako každý software, i tento prochází svým vývojovým cyklem a do budoucna se rozhodně počítá s rozšířením jeho funkcionality.

71

Závěr V čase, kdy probíhalo sepisování zadání a počáteční analýza, neexistovalo žádně komplexní řešení pro Windows Phone 7. Bylo zde pouze pár aplikací, které evidovali spotřebu, nebo náklady na auto. Žádná však neumožňovala vedení knihy jízd a komunikaci se serverem v takovém rozsahu, jako ukázala tato diplomová práce. Většina aplikací měla nevyhovující UI a neumožňovala export dat z telefonu. Světlou výjimkou je již zmiňovaná aplikace AutoManager, která prošla několika zásadními změnami až v době vývoje naši aplikace a stala se největším konkurentem našeho mobilního řešení knihy jízd. Cílem diplomové práce bylo v podstatě vytvořit 2 aplikace, fungující na jiných zařízeních, platformách a přesto spolupracujících. Byla úspěšně vytvořena mobilní aplikace pro zařízení Windows Phone 7, která byla v průběhu dubna 2012 nasazena na český Windows Phone Marketplace. Většina uživatelů tuto aplikaci používá samostatně, tedy bez druhé části diplomové práce - administračního rozhraní. Je to z toho důvodu, že mobilní aplikace byla uvolněna ke stažení zdarma, avšak z pochopitelných důvodů je již administrační rozhraní zpoplatněno - kromě nákladů na vývoj je potřeba brát v potaz i náklady spojené s nasazením a podporou v prostředí Sharepoint. I administrační prostředí si pomalu nachází své zákazníky, zejména z oblasti malých a středních firem disponujících prostředím Sharepoint. Vede je k tomu zejména možnost mít všechny údaje na jednom místě - Sharepoint. Při realizaci jsme se snažili co nejvíce držet analýzy, avšak v některých případech se to nepovedlo. Zejména při implementaci GUI mobilní verze aplikace došlo k drobným změnám vůči původnímu návrhu, který je vidět na wireframe. Změnila se pozice některých tlačítek, zobrazené informace a použité prvky pro zobrazení a navigace. Nejednalo se však o zásadní změny, spíše o kosmetické úpravy, které měli za úkol zjednodušit práci s aplikací a zlepšit celkový dojem z aplikace. Samotná funkčnost aplikace nebyl ovlivněna a držela se striktně analýzy. Na začátku bylo hodně nápadů, co by mohla aplikace umět, jak zjednodušit uživatelům práci. Avšak po menší diskusi jsme si uvědomili, že není možné všechny tyto funkce implementovat do verze 1.0, proto bylo hodně funkcí odloženo do dalších verzí, nebo označených jako „nice to have“ - funkce zajímavé, ale nepodstatné pro funkčnost aplikace. Tímto rozhodnutím jsme zkrátili dobu vývoje a otevřeli si cestu pro získání uživatelů již první verzí a také 73

Závěr k odladění samotné aplikace - ani navzdory důkladnému testování před nasazením, se vývojáři nevyhnou chybám. Kromě testování nám uživatelé poskytli i pár poznatků a nápadů, co by rádi viděli v dalších verzích. Díky tomu se můžeme do budoucna zaměřit na to, co je opravdu důležité. V budoucnosti bychom určitě rádi rozšířili aplikaci (jak mobilní, tak i webovou) o větší možnosti statistického zobrazení. Datových podkladů je již v současnosti více než dost, bohužel se zatím naplno nevyužívá jejich potenciál. V této části tedy vidíme značné rezervy. Zaznamenávání služebních jízd by určitě zpříjemnila možnost nahrávání trasy dle GPS v telefonu - i tato funkcionalita je plánována do další verze. Bylo myšleno i na možnost vyfotit účtenku z čerpací stanice a to z toho důvodu, že se účtenky často ztrácejí, nebo vyblednou a tímto způsobem by bylo možné alespoň částečně a jednoduše účtenky „zálohovat“. Po vyjmenování různých funkcí, které se plánují, je vhodné vyjmenovat i ty, které v nejbližší době v plánu nejsou. Nepočítá se s rozšířením mobilní aplikace na další platformy a to zejména z kapacitních důvodů - nedostatek programátorů zkušených s platformou Android nebo iOS. Momentálně ani není v plánu zpřístupnění administračního rozhraní veřejnosti. Doufáme, že se mobilní aplikace pro Windows Phone 7 úspěšně prosadí nejen v České republice, ale i na zahraničních marketplacech a najde si své spokojené uživatele.

74

Literatura [1]

Wikipedia. Windows Phone, leden 2012. citace ze dne 2. 2. 2012.

[2]

KnowYourMobile. Panel judged Operating System of the Year winner: Windows Phone 7, listopad 2011. citace ze dne 3. 2. 2012.

[3]

Tom Warren. Windows Phone wins IDEA 2011 – people’s choice design award, září 2011. citace ze dne 20. 3. 2012.

[4]

IXDA. Interaction Awards Winner 2012, únor 2012. citace ze dne 4. 3. 2012.

[5]

Microsoft. Metro design language of windows phone 7. citace ze dne 15. 3. 2012.

[6]

Todd Haselton. Microsoft’s metro-based xbox 360 dashboard update to launch december 6th, listopad 2011. citace ze dne 24. 3. 2012.

[7]

Douglas Gantenbein. Windows Phone 7: A Better Keyboard, duben 2011. citace ze dne 4. 3. 2012.

[8]

Appsfuze. TextTextRevolution!, duben 2011. citace ze dne 4. 3. 2012.

[9]

WindowsPhoneGeek. Things to consider when using WP7 Application Bar, říjen 2011. citace ze dne 10. 3. 2012.

[10] WMPoweruser. Windows Phone 7 crosses 2% market share in USA, has 7% of German market, srpen 2011. citace ze dne 3. 2. 2012. [11] Martin Pultzner. V ČR vládne Symbian a nejvíce na mobilu surfují Pražané (statistika), březen 2012. citace ze dne 20. 3. 2012. [12] Google. Hardware specifications for windows phone, 2012. citace ze dne 30. 3. 2012. [13] Microsoft. Visual Studio 11 Beta is here. citace ze dne 10. 3. 2012. [14] Microsoft. EXPRESSION BLEND AND SKETCHFLOW DEMO. citace ze dne 10. 3. 2012. 75

Literatura [15] Microsoft. SketchFlow. citace ze dne 10. 3. 2012. [16] Paul Andrew. 10 Completely Free Wireframing and Mockup Tools, únor 2011. citace ze dne 15. 3. 2012. [17] Microsoft. Windows Phone Emulator, březen 2012. citace ze dne 28. 3. 2012. [18] Microsoft. Hardware specifications for windows phone, březen 2012. citace ze dne 28. 3. 2012. [19] CodePlex. Sketchflow template for windows phone, leden 2012. citace ze dne 24. 3. 2012. [20] Telerik. Radcontrols for windowsphone, 2011. citace ze dne 29. 3. 2012. [21] Microsoft. Live sdk, 2012. citace ze dne 12. 4. 2012. [22] Flurry. Flurry, 2011. citace ze dne 2. 4. 2012. [23] GitHub. Expensify / windowsphonetestframework, 2012. citace ze dne 2. 4. 2012. [24] Microsoft. Application certification requirements for windows phone, březen 2012. citace ze dne 15. 4. 2012. [25] Wikipedia. Application certification requirements for windows phone, duben 2012. citace ze dne 15. 4. 2012. [26] Microsoft. Microsoft sharepoint 2010, 2011. citace ze dne 17. 4. 2012. [27] Xperiensis. Xperiensis, 2012. citace ze dne 17. 4. 2012. [28] Microsoft. Microsoft dynamics gp versus netsuite: Key reasons microsoft dynamics gp may be a better fit for your business, únor 2010. citace ze dne 20. 4. 2012. [29] Chris Dwyer. What will ms project 2010 mean for you?, duben 2010. citace ze dne 20. 4. 2012. [30] IBM. Filenet content manager, 2011. citace ze dne 20. 4. 2012. [31] Oracle. Oracle portal 11g release 1 (11.1.1.1.0), 2012. citace ze dne 20. 4. 2012. [32] Microsoft. Microsoft dynamics, 2011. citace ze dne 20. 4. 2012. [33] SAP. Sap, 2011. citace ze dne 20. 4. 2012. [34] Mittuniersitetet. Filenet, 2011. citace ze dne 20. 4. 2012. 76

Literatura [35] Rex Baldazo. Avoid oracle portal at all costs, září 2007. citace ze dne 20. 4. 2012. [36] Kai Wähner. Pros and cons – when to use a portal and portlets instead of just java web-frameworks, říjen 2011. citace ze dne 20. 4. 2012. [37] TheDailyWTF. Oracle portal stories?, leden 2008. citace ze dne 21. 4. 2012. [38] Oracle. Oracle webcenter, duben 2011. citace ze dne 26. 4. 2012. [39] WadiSAP. Sap, 2011. citace ze dne 20. 4. 2012. [40] Microsoft. Microsoft dynamics, 2011. citace ze dne 20. 4. 2012. [41] Microsoft. Microsoft project 2010, 2011. citace ze dne 20. 4. 2012. [42] Xperiensis. Uzivatelska dokumentace pro vyvoj pomoci hermes frameworku, 2010. [43] sqdw. Inversion of control, dependency injection, duben 2008. citace ze dne 18. 4. 2012. [44] Nunit. Nunit, 2007. citace ze dne 5. 4. 2012. [45] Fiddler. Fiddler web debugger proxy, duben 2008. citace ze dne 18. 4. 2012. [46] GHIelectronics. Ghielectronics, 2012. citace ze dne 23. 4. 2012. [47] GHIelectronics. Fez cerberus mainboard, 2012. citace ze dne 23. 4. 2012. [48] GHIelectronics. Obd ii module, 2012. citace ze dne 23. 4. 2012. [49] GHIelectronics. Bluetooth module, 2012. citace ze dne 23. 4. 2012. [50] E Lawrence. Fiddler web debugging proxy, 2011. citace ze dne 26. 4. 2012. [51] sizzlecode. Automanager, 2012. citace ze dne 17. 4. 2012. [52] Autologis. Autopark 2012, 2011. citace ze dne 17. 4. 2012. [53] KROBSOFTWARE. Autoplan, 2011. citace ze dne 17. 4. 2012.

77

PŘÍLOHA

Seznam použitých zkratek WP7 Windows Phone 7 GUI Graphical User Interface WPF Windows Presentation Foundation XNA Prostředí pro vývoj her od Microsoftu. XML Extensible Markup Language XAML Extensible Application Markup Language SDK Software Development Kit WVGA rozlišení Wide VGA 800 x 480 px A-GPS Asistovaná GPS UC UseCase, případ užití IDE Integrated Development Environment API Application Programming Interface JS JavaScript REST REpresentational State Transfer JVM Java Virtual Machine ECM Enterprise Concent Management BPM Business Process Management CRM Customer Realtionship Management

79

A

PŘÍLOHA

Ukázka výsledné aplikace

Obrázek B.1: Aplikace WP7: Úvodní obrazovka

Obrázek B.2: Aplikace WP7: Přidání jízdy 81

B

B. Ukázka výsledné aplikace

Obrázek B.3: Aplikace WP7: Výpis jízd

82

Obrázek B.4: Aplikace WP7: Přidání nové lokace - výběr na mapě

Obrázek B.5: Aplikace WP7: Přidání tankování

Obrázek B.6: Aplikace WP7: Výpis tankování

83


Obrázek B.7: Aplikace WP7: Ukázka formuláře pro export dat na SkyDrive

84

Obrázek B.8: Administrace: Ukázka samostatného modulu, který může běžet v prostředí Sharepoint, nebo jako samostatná webová stránka. Není zde zobrazeno nasazení v Sharepoint, protože se liší intranet od intranetu dle firemní identity. 85


Obrázek B.9: Administrace: Výpis jízd s možností filtrování podle každého sloupce. Zobrazení v prostředí Sharepoint.

86

Obrázek B.10: Administrace: Formulář pro přidání jízdy

87


Obrázek B.11: Administrace: Zobrazení trasy na mapě

88

Obrázek B.12: Administrace: Statistika vývoje spotřeby pro vybrané vozidlo

89

PŘÍLOHA

C

Obsah přiloženého CD Obsah CD, přiloženého k bakalářské práci, je zobrazen v tabulce C.1

Název mockups text text/thesis usecase

Popis Návrh GUI WP7 a administrační části - projekt programu SketchFlow adresář obsahující elektronickou verzi DP adresář obsahující zdrojové kódy k textu DP Enterprise Architect projekty s analýzou k WP7 a administrační části Tabulka C.1: Obsah přiloženého CD

91

Sem vložte zadání Vaší práce

Recommend Documents