eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£ové gra ky a interakce
Bakalá°ská práce
Aplikace mobilní £í²ník pro restaurace na platform¥ OS Android Václav Strnad
Vedoucí práce:
Ing. Pavel Vít
Studijní program: Softwarové technologie a management, Bakalá°ský Obor: Web a multimedia 23. kv¥tna 2012
iv
v
Pod¥kování D¥kuji vedoucímu práce Ing. Pavlu Vítovi za kontrolu a pomoc na projektu.
vi
vii
Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).
V Praze dne 25. 5. 2012
.............................................................
viii
Abstract This bachelors thesis is focused on application development for mobile OS Android. The aim of this application is to simplify the work of waiters, and thus increase the e ciency of the enterprise. The application will work so that a waiter receives the order from the guests, he writes it to the system and order will be sent to the central database, where other kitchen workers will be able to access it through the web application. The whole system is designed to simplify and accelerate the sharing of information between company employees. Acceleration of work with orders is in terms of e cient operation of the restaurant important to reduce the time customers wait for the ordered food. This step can increase the number of restaurant guests, thus turnover.
Abstrakt Bakalá°ká práce je zam¥°ena na vývoj aplikace pro mobilní systém OS Android. Cílem této aplikace je zjednodu²it práci £í²ník·m a tímto zvý²it efektivitu daného podniku. Aplikace bude pracovat tak, ºe £í²ník p°íjme objednávku od host·, zapí²e ji do systému a objednávka bude odeslána do centrální databáze, kde k ní ostatní pracovníci kuchyn¥ budou mít p°ístup pomocí webové aplikace. Celý systém má za úkol zjednodu²it a zrychlit sdílení informací mezi zam¥stnanci podniku. Zrychlení práce s objednávkami je z hlediska efektivního provozu restaurace d·leºité pro to, aby se zákazník·m zkrátila doba £ekání na objednané jídlo. Tímto krokem m·ºe restaurace zvý²it po£et host·, tudíº i obrat.
ix
x
Obsah 1 Úvod
1
2 Popis problému, speci kace cíle 2.1
2.2
Speci kace cíle
3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.1
Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.2
Vlastnosti výsledné práce
. . . . . . . . . . . . . . . . . . . . . . . . .
3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Re²er²e 2.2.1
Konkuren£ní °e²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1.1
Pokladní systém Harsys 6 . . . . . . . . . . . . . . . . . . . .
4
2.2.1.2
Programovatelný systém CONTO
5
. . . . . . . . . . . . . . .
3 Analýza a návrh °e²ení
7
3.1
Analýza moºných díl£ích °e²ení
. . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2
Analýza ceny a spot°eby návrhu . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3
asový plán . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.4
Poºadavky na výslednou platformu . . . . . . . . . . . . . . . . . . . . . . . .
8
3.5
Analýza úzkých míst návrhu . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.6
Stavební prvky °e²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.7
BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.8
Use cases
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.9
Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4 Prototyp
13
5 Realizace
17
5.1
5.2
5.3
Webová aplikace
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
5.1.1
Teorie
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
5.1.2
Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
Mobilní aplikace
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
5.2.1
Teorie
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
5.2.2
Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
Dal²í vývoj systému
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Testování
25
27
6.1
Testování prototypu
6.2
Testování gra ckého rozhraní
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xi
27 28
xii
7 Záv¥r
OBSAH
33
Seznam obrázk· 2.1
Pokladní terminál C.S.I. Star Touch
. . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Pokladní terminál C.S.I. Star Touch
. . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Vlevo: Sí´ová pokladní tiskárna Tysso PRP-085; Vpravo: Mobilní za°ízení pro £í²níkyC.S.I. French Touch . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.1
Vlevo: Proces objednání poloºky p°ed nasazením systému; Vpravo: Proces
3.2
Vlevo: Proces zaplacení ú£tu p°ed nasazení systému; Vpravo: Proces zaplacení . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.3
P°ípady uºití v mobilní aplikaci . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.4
Tabulky v databázi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
4.1
P°ihlá²ení do systému
13
4.2
Vlevo: Výpis ú£tenek v systému; Vpravo: Podrobnosti ú£tenky.
4.3
Vlevo: Kategorie jídelního lístku; Uprost°ed: Výpis speci cké kategorie jídel-
objednání poloºky po nasazením systému ú£tu po nasazení systému
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ního lístku; Vpravo: Podrobnosti poloºky jídelního lístku. . . . . . . . . . . . . 4.4
9
14 14
Vlevo: Kategorie nápojového lístku; Uprost°ed: Výpis speci cké kategorie nápojového lístku; Vpravo: Podrobnosti poloºky nápojového lístku.
. . . . . . .
15
. . . . . . . .
18
5.1
ivotní cyklus presenteru v Nette Framework, p°evzato z Nette
5.2
Vlevo: Vývojové prost°edí Eclipse; Vpravo: Emulované prost°edí pro test aplikací 20
5.3
ivotní cyklus activity, p°evzato z Android Developers
6.1
Sony Ericsson Xperia mini pro
. . . . . . . . . . . . . . . . . . . . . . . . . .
28
6.2
Druhý pokus o p°ihlá²en . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
6.3
Pohyb v seznam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
6.4
Vlevo: Podrobnosti stolu; Vpravo: Seznam s tla£ítkem zp¥t . . . . . . . . . .
31
6.5
Zobrazení Toastu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
xiii
. . . . . . . . . . . . .
21
xiv
SEZNAM OBRÁZK
Kapitola 1
Úvod Snahou provozovatel· restaura£ních za°ízení je obslouºit co nejvíce host· v co nejkrat²í dob¥, aniº by do²lo ke zhor²ení kvality jídla a obsluhy. Vzhledem k tomu, ºe doba p°ípravy jídel je dána vybavením kuchyn¥ a zku²eností a dovedností kucha°e, zam¥°íme se na zefektivn¥ní práce £í²ník·. Cílem bakalá°ské práce je vytvo°it aplikaci, která jim pom·ºe zkrátit dobu od p°ijetí objednávky do za£átku va°ení, zjednodu²í a zrychlí komunikaci £í²níka s kucha°em, p°ipraví podklady pro snadné vytvo°ení ú£tenky, a která v neposlední °ad¥ poskytne majiteli jasný p°ehled o provozu jeho restaurace. Snadno a rychle tak m·ºe reagovat na p°ípadné nedostatky chodu za°ízení. Tento nový systém mu poskytne jasné podklady pro hodnocení kvality práce personálu. Aplikace nahradí £asto pouºívaný "papírkový"systém p°ijímání objednávek, a tak i odstraní chyby, které vznikají jeho pouºíváním. Papírkový systém spo£ívá v tom, ºe £í²ník s blo£kem v rychlosti napí²e objednávku, kterou poté odná²í do kuchyn¥ a tlumo£í nebo p°episuje ji kucha°i. Tento systém je pomalý a mohou v n¥m lehce vznikat chyby. Aplikace tedy tyto zbyte£né kroky p°esko£í a nabídne jasné informace o objednávkách. Aplikace nabídne £í²ník·m dostate£n¥ jednoduché menu pro rychlý p°esun z elektronického jídelního lístku do objednávky, ty bude aplikace automaticky vkládat do centrální databáze, která bude p°ístupná pouze zam¥stnanc·m restaurace. Objednávky budou obsahovat informaci o tom, kdo si co objednal a kdo a kdy objednávku p°ijal. Systém tedy bude obsahovat t°i uºivatelské role, £í²ník, majitel a kucha°. Kaºdá z t¥chto rolí vyºaduje jiný druh p°ístupu i správy. í²ník bude vyuºívat rychlý p°ístup z mobilní aplikace. Majitel vyuºije p°ehledný výpis a správu v²ech informací v systému. Kucha° bude pot°ebovat jasný výpis objednávek, tak aby neztrácel £as s hledáním a £tením objednávek.
1
2
KAPITOLA 1.
ÚVOD
Kapitola 2
Popis problému, speci kace cíle 2.1 Speci kace cíle 2.1.1
Funk£ní poºadavky
Správa uºivatel·
Majitel restaurace bude moci p°idávat a odstra¬ovat uºivatele v sys-
tému.
Správa jídelního a nápojového lístku
V jídelním a nápojovém lísku budou uºivatelé
aplikace moci p°idávat kategie lístku, m¥nit je a odstra¬ovat. Do vzniklých kategorií budou poté moci p°idávat, upravovat a odstra¬ovat jednotlivé poloºky.
Správa ú£t·
í²ník bude oprávn¥n vytvá°et ú£ty pro nov¥ p°íchozí hosty. Ú£et bude mít
moºnost být p°esunut k jinému stolu. Nakonec bude £ísník moci ú£et ukon£it.
Správa objednávek
ísník bude moci p°idat novou objednávku na vybraný ú£et. V p°í-
pad¥ chyby objednávku bude moci zm¥nit nebo rovnou odstranit. Po dokon£ení p°ípravy objednávky k servírování ozna£í kucha° objednávku za p°ipravenou.
2.1.2
Vlastnosti výsledné práce
Uºivatelé
Cílovou skupinou uºivatel· jsou £í²níci, kterým aplikace umoºní rychlé a jedno-
duché zadávání objednávky do systému restaurace. Zjednodu²í se opravy p°ípadných chyb p°i objednávkách a urychlí £í²ník·m komunikaci s ostatními zam¥stnanci restaurace.
Aktivity
í²ník p°i p°íchodu k zákazník·m vybere st·l, ke kterému v systému vytvo°í
nový ú£et. Hosté nadiktují objednávku £í²níkovi, který v seznamu vybere jednotlivé poloºky, £ímº je p°idá na daný ú£et. Pokud hosté budou chtít zm¥nit objednávku, £í²ník opraví poloºky podle p°ání. Ve chvíli, kdy bude objednávka v po°ádku, £í²ník ji ode²le objednávku do systému. V tuto chvíli si objednávku uº p°evezme kucha°, pop°ípad¥ barman. Aº bude objednávka p°ipravena, dostane odpov¥dný £í²ník zprávu, aby odnesl objednávku zákazník·m. Nakonec £í²ník uzav°e ú£et, nechá ho vytisknout a doklad o zaplacení p°edá zákazníkovi.
3
4
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Uzav°ením ú£tu se v systému st·l uvolní a bude moºné po jeho obsazení dal²ím zákazníkem vytvo°it nový ú£et. Tak za£ne cyklus znova.
Podpora
Vytvo°ení prob¥hne p°ímo na st·l, který je volný. Objednávka bude de novaná
ú£tem a £í²níkem, který ji vytvo°il, tudíº aº bude objednávka hotová, daný £í²ník obdrºí upomínku aby odnesl objednávku. Aplikace bude vytvo°ena pro pouºití na mobilním za°ízení se systémem Android. Databáze, ke které bude aplikace p°istupovat bude na PC p°ipojené pomocí Wi- sít¥.
Kontext
Nejd·leºit¥j²í vlastností aplikace bude jednoduchost. ísník bude muset v pod-
stat¥ zárove¬ vid¥t poloºky, které si budou hosté vybírat, a aktuální ú£et pro p°ípadnou korekci. Dále musí být moºný rychlýp°esun, tak aby se objednávky daly rychle zadávat.
2.2 Re²er²e 2.2.1
Konkuren£ní °e²ení
2.2.1.1 Pokladní systém Harsys 6 [2]
Popis:
Restaura£ní software od rmy ABX software s.r.o. . Jedná se o celkový návrh sys-
tému, který umoº¬uje správu skladu, zam¥stnanc·, jídelního lístku v£etn¥ receptur a dal²í. Poºadovaný opera£ní systém, ve kterém bude software nainstalovaný, je Windows 2000 a nov¥j²í. Data se Ukládají v databázi SQL Firebird. Pouºívaný hardware je nap°íklad dotykový terminál (Obrázek 2.1), dále server s uloºenými daty a pokladní tiskárna. Moºnost roz²í°ení tohoto systému, je pouºít tzv. Mobilní PDA £í²ník. Toto PDA, po p°ipojení do systému pomocí sít¥ Wi- , jako standartní terminál.
Obrázek 2.1: Pokladní terminál C.S.I. Star Touch
2.2.
5
REERE
Moºné zp·soby instalace systému: •
Systém lze instalovat na jediné za°ízení, které slouºí jednak jako pokladna, jednak i jako úloºi²t¥ dat.
•
Systém lze instalovat na více za°ízení, která slouºí jako pokladny, jako po£íta£e v kancelá°ích nebo jako server. Ve²keré propojení je realizováno prost°ednictvím interních sítí.
•
Systém lze instalovat na r·zných za°ízeních jako v druhém bod¥. Propojení je realizované p°es internet.
•
Dal²ím zp·sobem instalace je propojení r·zných za°ízení v síti, prost°ednictvím které si tato za°ízení informace p°edávají. Za°ízení jsou po synchronizaci sob¥sta£ná.
Výhody systému:
Pokladní systém Harsys 6 díky své dlouhé existenci obsahuje mnoho
nástroj· pro správu skladu a provoz restaurace. Nabízí podporu r·zných periferií a pokladen.
Nevýhody systému:
Tento software je vytvo°ený pouze pro systém Windows. Technika
pouºívaná v sestavách má vysokou po°izovací cenu.
2.2.1.2 Programovatelný systém CONTO [7]
Popis:
Modulární systém pro hotely, obchody a restaurace rmy Novotný Atrima Brno.
Software vyuºívá rela£ní databázi Firebird SQL, podporuje formát XML pro sdílení informací. Výhodou systému je správa ú£t· v podob¥ gra cky znázorn¥né mapy stol·. Návrh vyuºívá dotykový terminál (Obrázek 2.2) p°ipojený k serveru a sí´ové tiskárn¥ (Obrázek 2.3 Vlevo) pro vyti²t¥ní ú£tenek. Roz²í°ením je mobilní za°ízení (Obrázek 2.3 Vpravo), které nabízí p°ístup do systému odkudkoli. Jediné omezení je dosah místní sít¥ v které je p°ipojené.
Obrázek 2.2: Pokladní terminál C.S.I. Star Touch
6
Výhody systému:
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Velkou výhodou systému Conto je moºnost jeho úpravy pro indivi-
duální pot°eby restaura£ních za°ízení. Pouºití tohoto systému je výhodné p°edev²ím pro za°ízení, které nabízejí kombinaci restaura£ních, hotelových za°ízeních i obchodech.
Nevýhody systému:
Modulárnost systému je zárove¬ jeho nevýhodou. Uºivatelské roz-
hraní totiº obsahuje nadmíru informací, které sniºují schopnost orientace v systému. Dal²í nevýhodou je velikost pouºitého mobilního za°ízení. Ta navíc mohou být v systému p°ipojena pouze £ty°i.
Pouºívaný hardware se systémem CONTO Aplikace na za°ízení PDA, která slouºí jako roz²í°ení pokladního systému. Aplikace simuluje pokladnu v mobilním za°ízení.
Obrázek 2.3: Vlevo: Sí´ová pokladní tiskárna Tysso PRP-085; Vpravo: Mobilní za°ízení pro £í²níkyC.S.I. French Touch
Kapitola 3
Analýza a návrh °e²ení 3.1 Analýza moºných díl£ích °e²ení Systém se zam¥°uje na správu dat v restauraci. Pro takovýto ú£el se nejvíce hodí informace ukládat databázovým systémem, který dokáºe pojmout obrovské mnoºství dat ve strukturované podob¥. Proto, aby byly náklady na software co nejniº²í, vyuºijeme open source databázi, moºnostmi je SQLite nebo MySQL. SQLite se v¥t²inou vyuºívá ve spojení s aplikacemi implementované v Jav¥. Ve webových databázích se zase pouºívá MySQL databáze. Tyto systémy mohou být nasazeny ve dvou zp·sobech, prvním je instalace na placeném serveru, druhou je soukromé za°ízení s instalovaným webovým serverem. Centrální aplikaci je pot°ebné implementovat v jazyce, který bude multiplatformní a bude jednoduché jej nasadit. Moºnostmi jsou Java nebo PHP. Oba jazyky umí pracovat s databázemi a jejich nasazení není problémem. V obou p°ípadech je pot°eda nainstalovat prost°edí, v kterém pob¥ºí. V p°ípad¥ Javy se jedná o JRE. U PHP jde o stejnojmený program v kombinaci se serverem Apache. Mobilní aplikace musí k centrální aplikaci p°istupovat p°es ²ifrované spojení, aby zamezilo úniku dat p°i bezdrátové komunikaci. Poºadavkem bylo ur£eno, ºe aplikace je ur£ena pro OS Android, coº je Java obohacená o knihovny p°ipravené k práci s periferiemi mobilních za°ízení.
3.2 Analýza ceny a spot°eby návrhu Po°izovací cena hardwaru dostate£n¥ výkonného pro b¥h jednoho serveru s databází a aplikací je 10000 K£. Pokud bychom cht¥li pouºít dotykový terminál s instalovaným serverem, jeho cena bude je²t¥ vy²²í. V p°ípad¥ konkuren£ních °e²ení se jedná £ástky okolo 25000 K£.Jediným omezením systému je nutnost pouºití mobilního za°ízení s OS Android nejlépe s dotykovou obrazovkou, v kterém lze vyuºít intuitivní ovládání. Ceny t¥chto za°ízení se pohybují jiº od 3000 K£. Cena softwaru není ur£ena. Ceny jsou pouze orienta£ní, získané z internetového obchodu Alza [3], ke dni 8. 5. 2012.
7
8
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
3.3 asový plán Vývoj systému je sou£ástí bakalá°ské práce. Proto musí být zprovozn¥ní základní funkcionality hotové ke dni 25. 5. 2012. Implementace dal²ích funkcí systému a technologií bude probíhat b¥hem následujících dvou m¥síc· tak, aby bylo moºné systém pln¥ nasadit v provozu restaura£ního za°ízení.
3.4 Poºadavky na výslednou platformu Nízká cena
Software nebude vyuºívat placený software t°etích stran. Cílem je dosáhnout
co nejniº²í ceny.
Ovladatelnost aplikace
Aplikace musí mít rychle ovladatelné rozhraní. Nasazení bude
v nejr·zn¥j²ích prost°edích, zatíºených nap°. hlukem i nedostatkem sv¥tla.
Systém mobilní aplikace
Mobilní aplikace bude navrºena pro systém OS Android. Vý-
hodou za°ízení s tímto systémem je jejich rychlé roz²i°ování, zp·sobené nabídkou kvalitních sluºeb a hardwarem ve v²ech cenových kategoriích.
3.5 Analýza úzkých míst návrhu P°eru²ení spojení mobilní aplikace se serverem
Aplikace bude navrºena tak, aby byla
schopná samostatného fungování v p°ípad¥ p°eru²ení spojení s centrální databází.
Neoprávn¥ný p°ístup
Webová aplikace musí být navrºena tak, aby osoba bez p°ístupo-
vých údaj· nemohla získat ani upravovat data v systému.
Kon ikty nahrávaných dat
Databáze centrální aplikace bude získávat data od mobilních
aplikací. Aplikace tedy budou posílat pouze informace o tom, jak data zm¥nit, ne v²ak výsledný stav vzniklý touto zm¥nou.
3.6 Stavební prvky °e²ení Celý systém bude tvo°en alespo¬ jedním mobilním za°ízením a serverem, ke kterému se mobilní aplikace p°ipojí v p°ípad¥ nedostatku vlastních informací nebo za ú£elem vloºení nových dat. Data budou uloºena na databázovém serveru MySQL instalovaném podle poºadavk· zákazníka, na hostingovaném serveru nebo na osobním po£íta£i, p°ipojeném k síti Wi- . Serverová £ást bude mít webový p°ístup pro správu uºivatel·m. Mobilní aplikace bude navrºena pro pouºití na za°ízení s opera£ním systémem OS Android. Kv·li poºadavku na rychlé ovládání, bude °e²ení obsahovat za°ízení se systémem ve verzi 3.0 a vy²²í. D·vodem jsou propracovan¥j²í ovládací prvky oproti star²ím verzím.
3.7.
BPM
9
3.7 BPM Restaura£ní za°ízení je místem, ve kterém jsou zavedeny ur£ité procesy, které je t¥ºké m¥nit. Nový systém proto musí tyto zaºité postupy tém¥° kopírovat. Mobilní aplikace by tedy m¥la pokrývat ve²keré procesy spojené s objenávkami v restauracích. Proces zadání objednávky probíhá dnes takto (Obrázek 3.1 Vlevo), po nasazení systému bude probíhat takto (Obrázek 3.1 Vlevo). Tímto se dosáhne v¥t²ího vyuºití £asu £í²ník·. í²níci budou moci být více u host·, coº p°edpokládám povede k jejich v¥t²í spokojenosti. Dal²í moºností jak zefek-
Obrázek 3.1: Vlevo: Proces objednání poloºky p°ed nasazením systému; Vpravo: Proces objednání poloºky po nasazením systému tivnit chod restaurace je zaplacení ú£tu. Stav p°ed nasazením (Obrázek 3.2 Vlevo) a stav po nasazení systému (Obrázek 3.2 Vpravo).
3.8 Use cases Podle poºadavk· jsem vytvo°il p°ípady uºití, které je v²echny musí pokrýt. Podle p°ípad· se poté naimplementují jednotlivé £ásti systému. Nejd·leºit¥j²í £ástí je mobilní aplikace,
10
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
Obrázek 3.2: Vlevo: Proces zaplacení ú£tu p°ed nasazení systému; Vpravo: Proces zaplacení ú£tu po nasazení systému
která má nasledující p°ípady (Obrázek 3.3).
3.9.
11
DATA MODEL
Obrázek 3.3: P°ípady uºití v mobilní aplikaci
3.9 Data Model Server bude v²echna data ukládat do své MySQL databáze. Pro ú£ely objednávek budou muset být vytvo°eny následující tabulky. (Obrázek 3.4) Tabulka
users
s daty o uºivatelích systému. Tabulka obsahuje id záznamu, uºivatelské
jméno, email, k°estní jméno a p°íjmení a roli, kterou zastupuje v systému. Pro p°ihlá²ení je uloºeno heslo a takzvaná s·l pro zvý²ení po£tu kombinací hesla, £ímº bude zaji²t¥na v¥t²í bezpe£nost systému. Tabulka
tables
obsahuje záznam pro kaºdý st·l v restauraci. U kaºdého záznamu evi-
dujeme id, jméno a tag uchovávající ozna£ení stolu. Tabulka
accounts ukládá záznamy o zákaznických ú£tech. Ú£ty obsahují id, cizí klí£ s id
stolu u kterého je ú£et vytvo°ený, stav, ve kterém se ú£et nachází, cizí klí£ s id £í²níka, který ú£et vytvo°il, £as vytvo°ení ú£tu a £as, kdy si zákazník p°ál zaplatit. Tabulka
navigation
obsahuje navigaci we webovém menu a kategorie v jídelním a ná-
pojovém lístku. Op¥t zde najdeme id záznamu, link ur£ující o jaký presenter jde ve webové aplikaci, popisek poloºky, role které mají do této sekce p°ístup, pozici uloºení ilustra£ního obrázku a id rodi£e. V p°ípad¥ ko°enového prvku je uloºená nula. Tabulka
items ukládá v²echny poloºky jídelního lístku v databázi. Jde zárov¥¬ i o jakýsi
seznam skladu. Obsahuje totiº id poloºky, popisek, mnoºství porcí, které si hosté je²t¥ mohou objednat. Dále obsahuje sloupce s cenou poloºky, podrobný popis poloºky, pozici uloºeného
12
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
navigation, kam poloºka pat°í. orders. Krom¥ id obsahuje cizí klí£ s id ú£tu, na který
obrázku a cizí klí£ s id kategorie v tabulce Nejrozsáhlej²í tabulkou je tabulka
se má p°ipsat, cizí klí£ s id poloºky, kterou si host objednal, mnoºství ozna£ující kolik si host objednal poloºek, stav objednávky, cizí klí£ s id na uºivatele systému, který objednávku vytvo°il, £as vytvo°ení objednávky a £as vy°ízení objednávky.
Obrázek 3.4: Tabulky v databázi
Kapitola 4
Prototyp [4] Prototyp uºivatelského rozhraní je vytvo°ený v aplikaci Balsamiq Mockups, kterou je moºné pouºívat na webových stránkach Balsamiq nebo ji instalovat na PC. Tato aplikace umoº¬uje navrhnout rozhraní aplikace pro otestování d°íve, neº se za£ne vytvá°et samotný program. Designové rozdíly mezi systémy iOS a OS Android nejsou p°i testování uºivatelského rozhraní podstatné, intuitivnost ovládání je srovnatelná. Celý prototyp slouºí pouze k otestování gra ckého rozhraní. Testováním takového prototypu m·ºeme zjistit nedokonalosti rozhraní je²t¥ p°ed zapo£etím implementace. V aplikaci Balsamiq Mockups jsem navrhl rozhraní prezentující £í²ník·m v restauraci otev°ené ú£ty, jídelní a nápojový lístek. Prototyp obsahuje t°i typy zobrazení. Jedním je obrazovka pro p°ihlá²ení, dal²í je výpis seznamu a poslední vypisuje podrobnosti ur£ité poloºky. První typ, který uºivatel uvidí, je p°ihla²ovací obrazovka pro autentizaci uºivatele p°ed vstupem do systému (Obrázek 4.1). Po p°ihlá²ení uvidí uºivatel na obrazovce t°i tla£ítka, která simulují záloºky odd¥lující od sebe ú£tenky, jídelní a nápojový lístek.
Obrázek 4.1: P°ihlá²ení do systému
13
Pod první
14
KAPITOLA 4.
PROTOTYP
záloºkou se nachází výpis ú£tenek (Obrázek 4.2 Vlevo). Po kliknutí na jednu z ú£tenek se uºivateli zobrazí podrobnosti zvolené ú£tenky (Obrázek 4.2 Vpravo). Pod druhou záloºkou se nachází jídelní lístek. Zde se uºivateli zobrazí kategorie jídel
Obrázek 4.2: Vlevo: Výpis ú£tenek v systému; Vpravo: Podrobnosti ú£tenky. (Obrázek 4.3 Vlevo). Po výb¥ru kategorie vidí £í²ník seznam poloºek spole£n¥ s jejich základními informacemi (Obrázek 4.3 Uprost°ed). Po kliknutí na zvolenou poloºku se zobrazí t°etí typ obrazovky, podrobný výpis (Obrázek 4.3 Vpravo). Pokud si zákazník bude chtít objednat danou poloºku, £í²ník klikne na tla£ítko objednat. V p°ípad¥, ºe si poloºku bude chtít objednat více zákazník·, £í²ník vybere z nabídky odpovídající mnoºství. Pod t°etí záloºkou se nachází nápojový lístek. Obsahuje kategorie nápoj· (Obrázek 4.4
Obrázek 4.3: Vlevo: Kategorie jídelního lístku; Uprost°ed: Výpis speci cké kategorie jídelního lístku; Vpravo: Podrobnosti poloºky jídelního lístku.
15
Uprost°ed). Jednotlivé kategorie obsahují p°íslu²né poloºky nápojového lístku(Obrázek 4.4 Uprost°ed). Kaºdou poloºkusi stejn¥ jako u jídelního lístku m·ºe uºivatel nechat vypsat podrobn¥ (Obrázek 4.4 Vpravo). Zde vybírá po£et poloºek, které si hosté objednávají. Prototyp uºivatelského rozhraní se skládá ze základních ovládacích prvk·. Díky kom-
Obrázek 4.4: Vlevo: Kategorie nápojového lístku; Uprost°ed: Výpis speci cké kategorie nápojového lístku; Vpravo: Podrobnosti poloºky nápojového lístku. binacím desítek prvk· lze vytvo°it tém¥° jakýkoli návrh tak, aby vyhovoval poºadavk·m výsledné aplikace. Výsledný prototyp m·ºe obsahovat pouze jednotlivé pr·chody, které budou pouºity p°i testování. Díky aplikaci Balsamiq Mockups lze n¥kterým prvk·m vytvo°it odkaz k jiné obrazovce. Participant poté v prototypu ozna£uje ovládací prvky, které m¥l problém najít, nebo prvky, které hledal a v prototypu v·bec nebyly. Prototyp je vytvo°ený pouze pro otestování ovladatelnosti v hektickém prost°edí. í²ník musí mít moºnost okamºitého p°esunu mezi jednotlivými poloºkami jídelního a nápojového lístku. Zárove¬ musí mít moºnost rychlé opravy v p°ípad¥, ºe host nebo samotný £í²ník p°i objednávání ud¥lá chybu.
16
KAPITOLA 4.
PROTOTYP
Kapitola 5
Realizace Systém je rozd¥len do dvou implementa£ních £ástí. Jednou z £ástí je d·vod projektu, mobilní aplikace, která bude pomáhat £í²ník·m s objednávkami. Druhou £ástí je podpora aplikace a moºnost konfortn¥j²í správy databáze, webová aplikace.
5.1 Webová aplikace Webová aplikace slouºí pouze jako správcovský a prezenta£ní nástroj, tudíº jsem se rozhodl vyuºít framework, který velice zjednodu²²í práci s databází a prezen£ní vrstvou v systému. Framework Nette jsem si vybral hlavn¥ kv·li velké základn¥ programátor·, kte°í jiº mnohokrát °e²ili problémy, s kterými jsem se pozd¥ji setkal p°i vývoji.
5.1.1
Teorie
[6]
app. Aby framework mohl efektivn¥ spravovat databázi, musel jsem upravit soubor ./config/config.neon. Hlavní sloºkou projektu, obsahující celou funkcionalitu aplikace, je sloºka
Ten obsahuje nastavení p°ístupu k databázi a dále tzv. factories, které vytváºejí v systému objekty, ty jednotlivé tabulky databáze a funkce, které nad ní m·ºeme volat. T°ídy reprezen-
./model, view aplikace je uloºeno ve sloºce ./templates ./presenters. P°íchozí poºadavek na aplikaci parsuje URL podle vzoru v souboru ./app/bootstrap.php.
tující objekty jsou uloºeny ve slo£ce
a controler je zde reprezentovaný presentery ve sloºce
Odsud je p°esm¥rovaný na vybraný presenter a ²ablonu. Dále v poºadavku m·ºe být uloºena cookie, kterou jiº presenter pouºije nap°íklad pro autentizaci uºivatele.
ivotní cyklus presenteru Kaºdý presenter má sv·j ºivotní cyklus (Obrázek 5.1), b¥hem kterého se volají dané funkce. První funkcí je
startup(),
v které se provádí obecné operace jako je autentizace, kontroly
a p°ípadné p°esm¥rování. Zatím nadochází k práci s daty speci ckými pro daný presenter. Ve funkci
action() provádíme operace, které ovliv¬ují následující render funkci, jako je výb¥r
pouºité ²ablona pro vykreslení atp. Ve funkci handle jsou odchytávány signály nap°íklad
17
18
KAPITOLA 5.
odeslání formulá°e s daty. Následuje funkce
REALIZACE
beforeRender(), kde si p°edp°ipravíme data renderNázev(). Název je sloºen
pro vykreslení. P°edem p°ipravená data vyuºijeme ve funkci
ze dvou £ástí, render zna£í, ºe se jedná o funkci pracující s ²ablonou a druhá £ást je názvem ²ablony, která se pouºíje.
Obrázek 5.1: ivotní cyklus presenteru v Nette Framework, p°evzato z Nette
ablony V Nette se jako ²ablonovací jazyk vyuºíváme jazyk latte. Kaºdý presenter má alespo¬ jednu svou vlastní ²ablonu, pokud se nespeci kuje jinak, volá se ²ablona
default.latte.
Pokud
je ²ablon více, vyb¥r té, která se nakonec bude vykreslovat, provedeme ve funkci action. Nap°íklad m·ºe dojíd k p°esm¥rování na chybové hlá²ení. V²echny tyto templaty se p°i vykreslování, postupn¥ vkládají do základní ²ablony
@layout.latte, který de nuje hlavi£ku
dokumentu a jeho základní strukturu.
5.1.2
Implementace
Aplikace obsahuje 6 ruzných typ·, je jím objekt pro ú£tenky (Accounts), poloºky v jídelním a nápojovém lístku (Items), kategorie menu a navigace (Navigation), objednávky (Orders), stoly (Tables) a uºivatele (Users).
5.2.
19
MOBILNÍ APLIKACE
Implementované presentery pro správu Prvním presenterem p°i vstupu na stránky, je huje
SignPresenter.php,
HomepagePresenter.php.
Dále sloºka obsa-
na který jsme p°esm¥rovaní, pokud nejsme p°ihlá²eni. Hlavním
SecurePresenter.php, ten v²em potomk·m de startup(), kde se zjistí, jestli je uºivatel p°ihlá²ený a pokud není, je p°esm¥rován zmi¬ovaný SignPresenter.php. Dal²ím obecným presenterem je ErrorPresenter,
presenterem, od kterého v¥t²ina d¥dí, je nuje funkci na jiº
na který se p°esm¥ruje, pokud se vyskytne v aplikaci chyba jako poºadavek na presenter, který v aplikaci neexistuje.
AccountsPresenter, ItemsPresenter, UserPresenter, umoº¬ující zm¥nu osob-
Následují presentery starající se o správu obsahu
OrdersPresenter, UsersPresenter
a presenter
ních údaj·. Kaºdý z t¥chto presenter· obsahuje výpis poloºek, které do danného presenteru pat°í a formulá°e pro p°idání a úpravu danných poloºek. Vytvo°ení formulá°e se provádí ve
name
funkcích s dannou strukturou hlavi£ky. Parametr
ozna£uje název formulá°e, který je
jmenován v ²ablon¥. Tím je moºné rozli²it více formulá°· na stránce.
protected function createComponentNázev($name){ ... } Ve funkci jsou poté vyjmenované poloºky, které se mají vykreslit, sou£asn¥ s vytvá°ením se i nastaví jejich typy a podmínky, které se mají hlídat. Standardn¥ se formulá° odesílá metodou POST. P°i odeslání formulá°e, se data ode²lou funkci pro odchycení signálu, ta poté zpracuje a uloºí data do databáze.
Presenter pro synchronizaci dat St¥ºejním presenterem je
JsonPresenter,
ten se stará o komunikaci s mobilní aplikací. Pre-
senter si z poºadavku získá POST data, která jsou ozna£ena jako json a uloºí si je v decodované podob¥. Tyto data obsahují pokyny ke spu²t¥ní speci cké funkce v dané t°íd¥. Volání funkce je realizované univerzální metodou
call_user_method().
Výsledek je zp¥tn¥
p°eveden do syntaxe json a odeslán jako odpov¥¤.
5.2 Mobilní aplikace Aplikace je vyvíjena v programu Eclipse Indigo (Obrázek 5.2 Vlevo) s nainstalovanou knihovnou SDK v4.0. SDK v sob¥ krom¥ nápov¥dy obsahuje je²t¥ programy, umoº¬ující vzniklý kód okamºit¥ nahrát do za°ízení s OS Android p°ipojeného k po£íta£i nebo vytvo°it gra cké virtuální prost°edí, které simuluje celý mobilní telefon (Obrázek 5.2 Vpravo). Toto prost°edí má ale oproti skute£nému mobilnímu za°ízení velkou nevýhodu. Simulovat takovéto prost°edí v po£íta£i je výpo£etn¥ i pam¥´ov¥ náro£né. Proto není zcela vhodné na n¥m testovat výkonnost nebo stabilitu aplikace.
20
KAPITOLA 5.
REALIZACE
Obrázek 5.2: Vlevo: Vývojové prost°edí Eclipse; Vpravo: Emulované prost°edí pro test aplikací
5.2.1
Teorie
Kaºdá mobilní aplikace vytvo°ená pro OS Android musí obsahovat tzv.
AndroidManifest.xml,
umíst¥ný v úvodní sloºce projektu, jde o XML soubor de nující samotnou aplikaci. Obsahuje, pro jakou verzi SDK je kód tvo°en a jaký minimální je vyºadován, jelikoº aplikace vyuºívá prvky z nov¥j²ích verzí systému. Pokud aplikace bude pracovat s n¥jakou periferií za°ízení, musí zde speci kovat oprávn¥ní k nim. Jsou jimi nap°íklad oprávn¥ní k p°ístupu na internet, práce s vybracemi a dal²í. Nakonec zde hlavn¥ najdeme entity
activity.
Jde
o záznamy v²ech activit v aplikaci, které se budou zobrazovat uºivateli. Pokud n¥jaká z nich nebude zde zmín¥ná, aplikace activitu neotev°e a zahlásí chybu. Kaºdá znich obsahuje název t°ídy, v které je aktivita implementována. Pochopiteln¥ entity neobsahují pouze atributy se jménem, ale i m·ºeme zde nastavit i popisek nebo základní styl, ve kterém se obrazovka vykreslí. Záznam hlavní activita, která se má spustit kdyº kliknete na ikonu aplikace v seznamu aplikací, obsahuje
intent-filter.
Ten, jak název napovídá, ltruje ozna£uje activitu za hlavní a spustitelnou. P°ípad¥ p°ijetí odpovídající zprávy, kterou je p°íkaz ke spu²t¥ní aplikace, se aktivuje práv¥ tato aktivita a ne jiná z aplikace.
Activity Nyní p°ejdeme k jiº zmín¥ným activitám, uloºených ve sloºce
./src. Activita je t°ída, která
ovládá gra cké rozhraní. Stejn¥ jako presentery v Nette mají ºivotní cyklus, kterým se
5.2.
21
MOBILNÍ APLIKACE
prochází od chvíle, kdy activita vzniká aº do doby, kdy zanikne (Obrázek 5.3). Metoda
onCreate(), která se volá p°i spu²t¥ní activity, slouºí k inicializacím prom¥nných a k prvotnímu vykreslení obrazovky. Naopak v metod¥ onDestroy uzavíráme komunikaci a activita kon£í.
Obrázek 5.3: ivotní cyklus activity, p°evzato z Android Developers
Velkou £ástí aplikace jsou XML soubory de nující rozli£ný obsah a obrázky uloºené v ad-
./res. Rozloºení a základní strukturu obrazovky, je de nované v ²ablonách, v adresá°i ./res/layout. Tyto ²ablony vytvá°íme, pokud pot°ebujeme mít specializovanou strukturu resá°i
obrazovky. ablona obsahuje ko°enovou entitu ur£ující strukturu. Do té se vkládají dal²í entity de nující prvky na obrazovce. Elementy obsahují atributy id pro odli²ení více stejných element· na obrazovce, nastavení zarovnání nebo p°edde novaný text a dal²í.
Menu V aplikaci m·ºeme dále vyuºít menu bor· se odli²ují ko°enovým elementem
./res/menu. Krom¥ uloºení od ostatních XML sou<menu> obsahující prvky
- , coº jsou jiº samotné
poloºky menu. Atributy de nují id a v praxi se jim uº p°edem nastaví popisek.
22
KAPITOLA 5.
REALIZACE
P°edde nované hodnoty v aplikaci ./res/values. ,
Ur£ité hodnoty, jako t°eba texty, si m·ºeme p°edde novat v souborech v adresá°i Jde rovn¥º o XML dokumenty. Ko°enovým elementem v t¥chto souborech je
ty obsahují prvky podle toho jakou hodnotu si chceme p°ede novat. P°íkladem element pro p°edde nování si textu obsahující název aplikace.
<string name="app_name">MobileWaiter
Obrázky Ikony, které bychom cht¥li n¥kde vykreslovat, musíme uloºit do sloºek za£ínajících
drawable,
ve formátu PNG a zárove¬ ve dvou formátech, jeden pro stisknutý a druhý pro nestisknutý stav. Jelikoº systém OS Android je na za°ízeních s °·zným rozli²ením a formát PNG není vektorový, °e²í se to uloºením ikon rovn¥º v n¥kolika rozli²eních. Ikony s extrémn¥ vysokým rozli²ením 96 x 96 px se uloºí do sloºky 72 x 72 px do sloºky s p°íponou
drawable
s p°íponou
-xdpi,s
vysokým rozli²ením
-hdpi, se st°ední kvalitou 48 x 48 do sloºky s p°íponou -mdpi -ldpi. Verzi ikony si poté aplikace
a nakonec nejniº²í kvalita 36 x36 px ve sloºce s p°íponou
automaticky vybere ze souboru, kde jsou verze ikon s danným názvem zaindexované.
5.2.2
Implementace
[5] [1] Po nainstalování SDK do programu Eclipse jsem mohl rovnou vytvo°it Android Project. Eclipse mi poté vygeneroval celou strukturu se základními soubory v£etn¥ úvodní activity s názvem projektu MobileWaiter. Rovn¥º se teda i tato activita nastavila v AndroidManifestu jako hlavní a má se tedy spustit, pokud vyvolám aplikaci v menu. Hlavní activita obsahuje de nici záloºek, proto jsme ji nastavili jako potomka t°ídy TabActivity, tedy activity, která bude spravovat záloºky. Kaºdou ze záloºek musíme vytvo°it zvlá²´. Nejd°íve si vytvo°íme jakýsi spou²t¥£, kterému nastavíme t°ídu, kterou chceme, aby se otev°ela pod záloºkou, pokud na ni klikneme. Dále získáme view, do kterého budeme ukládat záloºky a uloºíme do prom¥nné
tabhost.
Samotné naprogramování záloºky p°ichází teprve
te¤. Nad objektem view vytvo°íme novou speci kaci záloºky se jménem account a nastavíme mu popisek a p°idáme ikonu s názvem ic_tab_account. Nakonec speci kaci p°idáme do view.
Intent intent = new Intent().setClass(this, AccountActivity.class); TabHost tabHost = getTabHost(); TabHost.TabSpec spec; spec = tabHost.newTabSpec("account").setIndicator("Account", res.getDrawable(R.drawable.ic_tab_account)) .setContent(intent); tabHost.addTab(spec);
5.2.
23
MOBILNÍ APLIKACE
Seznam ú£t· První záloºka otvírá activitu s výpisem ú£tenek. Tato activita d¥dí od znamená, ºe v sob¥ bude obsahovat seznam poloºek. Ve funkci
ListActivity,
coº
onCreate nainicializuje p°ipo-
jení k SQLite databázi. Následn¥ z databáze získá v²echny ú£tenky, z kterých vytvo°í seznam a vloºí si ho sám do sebe. P°ed vloºením nad seznamem vytvo°í listener, který odchytává moºnost mnohonásobného vybrání poloºek. Abychom mohli p°idávat ú£tenky, musí si u aktivity vytvo°it menu. To vzniká ve funkci
onCreateOptionMenu(). @Override public boolean onCreateOptionsMenu(Menu menu) { MenuInflater inflater = getMenuInflater(); inflater.inflate(R.menu.options_menu, menu); return true; } Následn¥ ve funkci
onOptionItemselect() odchytáváme výb¥r poloºky v menu a podle toho
vyvoláme akci. Poloºky tohoto menu se de nují pro celou aplikaci. Pokud chceme vytvo°it menu pro konkrétní poloºku v seznamu, musíme vytvo°it kontextové menu. Toto menu se aktivuje p°i dlouhém stisku poloºky v seznamu. Rovn¥º musíme °e²it odchycení výb¥ru menu a podle toho vyvolat ur£itou akci. Aby se vypsal obsah ú£tenky, musí být zavolaná jiná activita, která tento obsah vypí²e. Proto seznam ú£tenek obsahuje funkci
onListItemClick(), tak jako parametr dostane
celý seznam a pozici prvku na který uºivatel klikl. Problémem této funkce je, ºe se volá i p°i n¥kolikanásobném vybírání poloºek, proto se v ní musí kontrolovat, jestli daná poloºka není v tomto problematickém výb¥ru. Pokud není vytvo°í se spou²t¥£ s aktivitou pro výpis ú£tenky, kterému se navíc p°edá informace o tom, jakou ú£tenku má vypsat, a activita se spustí.
Intent accountContent = new Intent(this, AccountContentActivity.class); accountContent.putExtra("com.strnava1.mobileWaiter.accountId", ((Account) item).getId()); startActivity(accountContent); V activit¥ jsou navázané listenery na tla£ítkách cancel a ok. Po vybrání stolu a kliknutí na tla£ítko OK se spustí funkce, která získá data o stolu a podle toho vytvo°í ú£et. Nejd°íve si najdeme ve view prvek podle id, které jme nastavili v ²ablon¥. To nám vrátí objekt typu view proto, abychom z n¥j mohli získat obsah, musíme ho p°etypovat na jeho potomka
Spinner, coº je rozklikávací seznam. Z n¥ho ale získáme typ Object. Jelikoº v aplikaci mám jiº vytvo°ený objekt Table, mohu Object p°etypovat a následn¥ z n¥ho získat v²echny informace, jako je název a podobn¥.
Table table = ((Table)((Spinner) findViewById(R.id.table)) .getSelectedItem()); Upravení ú£tenky je realizované z kontextového menu. P°i odchycení akce edit se otev°e nové okno, kde je jiº p°edem vypln¥ný st·l, u kterého je zapsaný upravovaný ú£et.
24
KAPITOLA 5.
REALIZACE
Jídelní a nápojový lístek Ob¥ záloºky obsahují stejný kód. V obou p°ípadech nejd°íve zobrazuji navigaci lístku, tedy kategorie pokrm· nebo nápoj·. V tuto chvíli je v menu nastaveno, aby bylo moºné p°idávat pouze kategorie lístku. V p°ípad¥ kliknutí na poloºku navigace nevolám novou aktivitu s obsahem ur£itého druhu, ale pouze zm¥ním obsah seznamu na poloºky v dané kategorii. Nyní akce pro p°idání poloºky vyvolá activitu pro p°idání pokrmu nebo nápoje, nikoli p°idání kategorie. Zamezil jsem tím vytvá°ení nadm¥rn¥ rozsáhlých strom· jídelní£ku, který by zhor²oval ovladatelnost. Smazání a úprava kategorie nebo jídla a nápoje je realizováno stejným zp·sobem, jako v p°ípad¥ ú£tenek. P°epsání seznamu místo otev°ení nové activity jsem zvolil proto, aby bylo moºné rychleji p°echázet mezi ob¥ma lístky. Teprve, kdyº se zobrazují poloºky jídel nebo nápoj·, se po kliknutí na poloºku otev°e nová obrazovka s podrobnostmi poloºky. Aktivita s podrobnostmi jídla nebo nápoje nabízí uºivateli v²echny informace, které by mohl host, který si bude objednávat, pot°ebovat. Zárove¬ zde uºivatel vytvo°í objednávku na aktuální poloºku. V p°ípad¥, ºe by více host· cht¥lo tuto poloºku, m·ºe uºivatel zvý²it mnoºtví poloºek v objednávce.
SQLite databáze Databáze je základem celé aplikace. V²echna data, který uºivateli aplikace prezentuje jsou
DbAdapter. Obsahuje pouze dv¥ funkce. První funkce open() DatabaseHelper, která fakticky komunikuje s databází a nechá si od ní vrátit p°ístupnou databázi. Druhou funkcí je funkce close, ta pomocí t°ídy DatabaseHelper uzav°e databázi. T°ída DatabaseHelper je potomkem SQLiteOpenHelper, v ní uloºeny. Hlavní t°ídou je
si v sob¥ vytvo°í instanci t°ídy
získává tím metody volané p°i vytvá°ení databáze a funkce které mají p°ístup k databázi.
onCreate() dostává parametrem tabulky. Metodou onUpdate, volané p°i
Table
V metod¥
datábázi, v které si nechá t°ídou
°it
zm¥n¥ verze databáze, si op¥t od t°ídy
nechám odstranit a znovu nahrát databázi. T°ída
Table
vytvo-
Table
obsahuje hlavn¥ konstaty s SQL
p°íkazy pro vytvo°ení tabulek a p°idání ko°enových poloºek v navigaci. Jednu poloºku pro jídelní a druhou pro nápojový lístek. Ke kaºdé tabulce v databázi existuje jeden adapter. Kaºdý z nich je potomkem
DbAdapter
a je obohacen o funkce pro práci se svojí tabulkou. Pro práci se záznamy jsou v SDK p°i-
insert() vloºí záznam, update() aktualizuje °ádek odpovídající podmínce delete() smaºe záznam který odpovídá podmínce a query() sloºí ke klasickému
pravené funkce, ve funkci, dotazu.
Funkce insert a update vyºadují data uloºená v objektu
ContentValues.
Jde o ty obsa-
hující dvojice klí£ a hodnota.
ContentValues values = new ContentValues(); values.put(KEY_ID, id); Obdobný problém je zp¥tn¥ p°i získávání dat z databáze. Funkce query nevrací pole dat, ale vrátí objekt
Cursor,
coº je pouze ukazatel na výsledek dotazu. Problémem je, ºe tento uka-
zatel ani neukazuje na první poloºku, proto je nutné p°ed prvním získáváním dat, p°esunout ho na za£átek.
Aplikace, kdyº si poºádá adaptér t°eba o v²echny ú£tenky, £eká, ºe adap-
tér vrátí seznam objekt· Account. Bohuºel se kv·li objektu
Cursor
není moºné oby£ejné
5.3.
DALÍ VÝVOJ SYSTÉMU
25
p°etypování. Proto musí být v kaºdém adaptéru aplikace pro získání dat cursoru a postupné uloºení jich do objekt·. Tímto zp·sobem jsem dosáhl jednoduchého ORM.
5.3 Dal²í vývoj systému Webová aplikace není pln¥ dokon£ená. Zatím je implementovaná pouze £ást umoº¬ující správu dat a vzdálenou synchronizaci s mobilním za°ízením. Do budoucna je moºné systém obohatit o £ást pro zákazníky. Ti by na stránkách mohli rezervovat místa v restauraci nebo si p°edem objednat speciální nabídku. Krom¥ jídelní£ku by systém mohl obsahovat správu skladu a automatickou kontrolu zásob. Dal²í implementa£ní £ástí by mohlo být ú£etnictví výpisem r·zných statistik o prosperit¥ restaurace. Mobilní aplikace je²t¥ nevyuºívá plného potenciálu za°ízení, na kterém bude nainstalována. Pro zlep²ení práce lze do aplikace p°idat upozor¬ování dlouhém £ekání zákazník·. Velkým potencionálem je implementace technologie NFC. Ta by mohla být vyuºita pro identi kaci stolu, u kterého £í²ník stojí a podle toho vybrat ú£et zákazník·. Nebo pro vyuºití nov¥ nasazovaného placení bezkontaktní platební kartou. Dal²í moºností je vytvo°ení v systému chat pro lep²í komunikaci zam¥stnanc· s majitelem podniku. Zam¥stnanci by tak mohli snadn¥ji informovat majitele o stavu skladu nebo technických problémech.
26
KAPITOLA 5.
REALIZACE
Kapitola 6
Testování 6.1 Testování prototypu Pro testování uºivatelského rozhraní vyuºiji Heuristickou evaluaci, pomocí které zjistím nedostatky v návrhu. Testování prob¥hlo pouze na jednom expertovi a jednom laikovi. Oba participanti m¥li splnit dva úkoly.
1. P°íhlaste se do systému. Zjist¥te, co májí hosté objednané u stolu £. 1 a sd¥lte to moderátorovi. 2. Dva hosté u stolu £. 6 si cht¥jí objednat bramborovou polévku. Nyní zadejte objednávku. Poté si host chce objednat Coca-Colu. Vstupte do nápojového lístku aº k poloºce Coca-Cola, ale je²t¥ neº ji objednáte, host zru²í poºadavek. Místo toho si objedná Plze¬ 12.
Výsledky testování: 1. Uºivatel se nachází v podrobnostech ú£tenky, zprvu neví, jak p°idat objednávku. eká tla£ítko P°idat objednávku v zobrazených informacích ú£tenky, na kterou si hosté cht¥jí objednat. 2. V p°ípad¥, ºe se uºivatel chce v menu vrátit o jednu úrove¬ zp¥t, volí automaticky tla£ítko pro p°esun na za£átek menu, místo aby pouºil moºnost seznamu v horní li²t¥.
Doporu£ení: 1. P°idat k rozpisu objednávek tla£ítko p°idat objednávku, která uºivatele p°esune na jídelní lístek. 2. Zvýraznit moºnost vracet se ve stromové struktu°e nap°íklad pomocí tla£ítek.
27
28
KAPITOLA 6.
TESTOVÁNÍ
6.2 Testování gra ckého rozhraní Testování probíhalo tak, ºe jsem m¥l k dispozici dva participanty, kte°í m¥li splnit zadané úkoly. Úkoly jsem vytvo°il, abych otestoval funk£nost uºivatelského rozhraní. Úkoly v zadání donutili participanta projít co nejv¥t²í £ástí aplikace. Participant se tedy dostal do stavu, kdy mu v návrhu n¥co chyb¥lo
Místo testování
Testování probíhalo v domácím prost°edí. Participanta jsem usadil ke
stolu, kde m¥l p°ipravený mobilní telefon s nahranou aplikací MobileWaiter a úkoly, které m¥l participant splnit.
Testovací za°ízení
Aplikace byla nahrána na mobilním za°ízení Sony Ericsson Xperia
mini pro (Obrázek 6.1) s opera£ním systémem Android verze 2.3.3. Celé testování jsem zaznamenával na kameru zna£ky JVC.
Obrázek 6.1: Sony Ericsson Xperia mini pro
Pr·b¥h testování
Participanty jsem nejd°íve seznámil s prost°edím, ve kterém bude test
probíhat a se zp·sobem testování. Dále jsem je seznámil se za°ízením, na kterém test budou plnit, abych sníºil jejich p°ípadnou nezku²enost s rozhraním systému Android a jeho ovládáním. Kaºdý z participant· na za£átku testu dostal následující seznam úkol·.
Úkoly pro participanty: 1. Zapn¥te aplikaci MobileWaiter. 2. P°ihla²te se do aplikace : (a) Zkuste, jestli se tam dostanete bez pomoci. (b) Moderátor Vám °ekne p°ihla²ovací údaje, zkuste se p°ihlásit znovu. 3. Podívejte se na podrobnosti stolu 3 a 7.
6.2.
TESTOVÁNÍ GRAFICKÉHO ROZHRANÍ
29
4. Hosté si cht¥jí objednat pepsi a gambrinus, ²unku s k°enem, 2 bramborá£ky, ku°ecí °ízek s hranolkami a vep°ové medajlonky s americkými bramborami. 5. Pop°ejte host·m dobrou chu´ a vypn¥te aplikaci.
Participant 1 Úkol £. 1:
Participant po chvíli hledání nalezl aplikaci v seznamu a spustil jí.
Úkol £. 2a:
Participant nejd°íve hledal n¥jaké menu, kde by byla poloºka p°ihlásit, netu²il,
ºe p°ihlá²ení práv¥ vidí. Následn¥ se pokusil do uºivatelského jména a hesla napsat svoje k°esní jméno a p°ihlásit se. Po zobrazení hlá²ky, ºe zadal ²patné jméno nebo heslo pokra£oval na dal²í úkol.
Úkol £. 2b:
Participant poºádal moderátora o p°ihla²ovací údaje a zkusil se p°ihlásit znovu.
Nyní úsp¥²n¥. Aplikace po p°ihlá²ení zobrazila aktivitu se záloºkami.
Úkol £. 3:
Participant nem¥l problém se zobrazením podrobností ke stol·m.
Úkol £. 4:
Participant pochopil zadání tak, ºe rovnou vstoupil do menu s nápoji, aby za£al
s objednávkou.Ne°e²il, k jakému stolu nebo jakým host·m objednávku zapsat. Jelikoº participant vlastní mobilní telefon se systémem Android, ovládání dotykem pro n¥ho nebyl problém. Kv·li zku²enostem pouºíval pro návrat zp¥t v menu hardwarové tla£ítko, místo poloºky v seznamu, £ímº ukon£il aktivitu se záloºkami a vrátil se k p°ihla²ovacímu formulá°i. P°ihla²ovací údaje byly stále zadané, tudíº klikl na tla£ítko p°ihlásit se a pokra£oval v pln¥ní úkolu. Tento problém se vyskytl je²t¥ dvakrát, participant se tuto chybu nedokázal odnau£it.
Úkol £. 5:
S ukon£ením aplikace nebyl problém. Tla£ítky zp¥t vypnul aplikaci.
Participant 2 Úkol £. 1:
Participant po chvíli hledání nalezl aplikaci v seznamu a spustil jí.
Úkol £. 2a:
Participant zkusil náhodné znaky v p°ihla²ovacím formulá°i a pokusil se p°i-
hlásit. Aplikace ho upozornila na ²patné p°ihla²ovací údaje a nepustila ho dál.
Úkol £. 2b:
Participant poºádal moderátora o p°ihla²ovací údaje a zkusil se p°ihlásit znovu.
(Obrázek:6.2) Nyní úsp¥²n¥. Aplikace po p°ihlá²ení zobrazila aktivitu se záloºkami.
Úkol £. 3:
Participant si postupn¥ zobrazil informace o stolu 3 a 7.
Úkol £. 4:
Uºivatel si p°e£etl zadání a p°ed zadáváním objednávky cht¥l vybrat st·l nebo
hosty, ke kterému by objednávku zapsal. Podle instrukcí moderátora pokra£oval v zadávání objednávky. (Obrázek 6.3) Po objednání se participantovi objevil Toast s popiskem, ºe poloºku objednal, tento popisek byl umíst¥n u jiného prvku v seznamu neº který objednával. U tohoto participanta se znovu objevil problém, kdy v seznamu klikl na hardwarové tla£ítko zp¥t, coº vedlo k uzav°ení aktivity a návratu k p°ihla²ovacímu formulá°i.
Úkol £. 5:
S ukon£ením aplikace nebyl problém. Tla£ítky zp¥t vypnul aplikaci.
30
KAPITOLA 6.
TESTOVÁNÍ
Obrázek 6.2: Druhý pokus o p°ihlá²en
Obrázek 6.3:
Shrnutí testování
Pohyb v seznam
Testování prob¥hlo bez v¥t²ích problém·, jako je nap°. stabilita pro-
gramu. V uºivatelském rozhraní se na²lo n¥kolik chyb. Pro následující implementaci aplikace bych doporu£il odstran¥ní poloºky zp¥t v seznamech (Obrázek 6.4) a p°evedení její funkce na hardwarové tla£ítko, p°ípadn¥ na kliknutí na p°íslu²nou záloºku. Dále v podrobnostech stolu (Obrázek 6.4) doporu£uji p°idat tla£ítko, které by vedlo k p°idání nové objednávky k p°íslu²nému stolu. Zobrazení informace o objednání není dosta£ující, zpráva, kterou uºivatel vidí neobsahuje dostatek informací, které by si spojil s úsp¥²ným objednáním poloºky. Zárove¬ je problém v umíst¥ní tohoto Toastu (Obrázek 6.5). Moºným °e²ením je zm¥nit formát zprávy z Toastu na n¥jaký jiný.
6.2.
TESTOVÁNÍ GRAFICKÉHO ROZHRANÍ
Obrázek 6.4: Vlevo: Podrobnosti stolu; Vpravo: Seznam s tla£ítkem zp¥t
Obrázek 6.5: Zobrazení Toastu
31
32
KAPITOLA 6.
TESTOVÁNÍ
Kapitola 7
Záv¥r Vytvo°il jsem základ pro nový systém k usnadn¥ní a zefektivn¥ní provozu restaura£ních za°ízení. Tento systém umoº¬uje £í²ník·m zaloºit ú£et k ur£enému stolu, provést elektronickou objednávku, odeslat ji do systému a umoº¬uje zobrazit ú£tenku. Pro mobilní aplikaci jsem navrhl prototyp uºivatelského rozhraní. Provedl jsem test jeho funk£nosti na dvou participantech, který potvrdil, ºe i laik dokáºe aplikaci snadno ovládat. Naprogramoval jsem webový server, který spravuje centrální databázi obsahující ve²keré informace v systému. Personál restaura£ního za°ízení má tak snadný p°ístup ke v²em informacím o nabízených jídlech a nápojích. Webová aplikace implementuje v sob¥ vytvá°ení a správu ú£t· jednotlivých uºivatel·, jídelního a nápojového lístku. Systém umí zobrazit objednávky, ú£tenky. Server umí komunikovat s mobilní aplikací. Nová mobilní aplikace obsahuje funkcionalitu pro vytvá°ení ú£t· a objednávek, které se automaticky odesílají do centrální databáze. Pln¥ nahrazuje stále £asto pouºívané zapisování objednávek na papír a umoº¬uje rychlý p°ístup k zadaným informacím dal²ím uºivatel·m systému (nap°. kucha°·m), coº zna£n¥ urychlí provoz restaurace. Vyuºil jsem nejnov¥j²ích ovládacích prvk· Androidu 3.0 a vy²²ího, aby ovládání aplikace bylo co nejjednodu²²í. Funk£nost této aplikace jsem otestoval na t°ech participantech. V²ichni t°i dokázali s novou aplikací pracovat úsp¥²n¥. Test odhalil n¥kolik malých nedostatk·. Týkaly se nejasného zp·sobu p°idání objednávky k ur£enému ú£tu. Na základ¥ toho zji²t¥ní jsem aplikaci roz²í°il o tla£ítko pro p°idání dal²í objednávky. Dále jsem nahradil harwarovým tla£ítkem nep°íli² vhodn¥ implementovaný zp·sob návratu ze seznamu jídel do seznamu kategorií. Výslednou implementaci aplikace se poda°ilo dostat do stavu, který je uºivatelsky p°ístupný. Aplikace je zprovozn¥na do té míry, ºe ji lze nasadit do plného provozu restaurace, p°estoºe se je²t¥ nejedá o nální verzi. P°edpokládám, ºe uºití této aplikace v praxi ukáºe p°ípadné dal²í nedostatky, protoºe byla otestována pouze v simulovaných podmínkách. Cíl bakalá°ské práce byl spln¥n. V dal²í fázi vývoje tohoto nového systému se chystám vyuºít co nejv¥t²ího potenciálu mobilního za°ízení, jakým jsou vibrace, noti ka£ní li²ta, gyroskop nebo technologie NFC. Dal²ím roz²í°ením systému je moºnost p°ímého tisknutí ú£tenek, vytvá°ení statistik, správy skladu, apod.
33
34
KAPITOLA 7.
ZÁV
R
Zkratky JRE V angli£tin¥ Java Runtime Environment. MySQL Je databázový systém, který pro komunikaci vyuºívá SQL. Systém je ve°ejný a bezplatný, jelikoº není vytvo°en pouze pro jeden systém, m·ºete ho nainstalovat na jakýkoli po£íta£ £i server. NFC V angli£tin¥ Near Field Communication. Jde o bezdrátovou technologii na krátké vzdálenosti v °ádu jednotek centimetr·. ORM V angli£tin¥ Object-relational mapping, v £e²tin¥ známé jako Objektov¥ rela£ní mapování. Jedná se o konverzi záznamu v tabulce do odpovídajícího objektu v objektov¥ orientovaném programování. PC Personal computer PDA Z angli£tiny Personal Digitam Assistant, do £e²tiny p°eloºeno jako Osobní digitální pomocník. Jde o kapesní po£íta£ obvykle ovládaný stylusem, coº je malé pero, na který je citlivá dotyková obrazovka. PHP Jde o rekuzivní z kratku v angli£tin¥ PHP: Hypertext Preprocessor. SDK V angli£tin¥ Software development kit, jedná se o nástroj obsahující p°edp°ipravený kód umoº¬ující programátor·m rychlej²í vývoj aplikací. SQL Z angli£tiny Structured Query Language, jedná se o dotazovací jazyk poºívaný v rela£ních databázích. Wi- Jedná se o bezdrátovou technologii pro komunikaci v po£íta£ové síti.
35
36
KAPITOLA 7.
ZÁV
R
Obsah p°iloºeného CD CD |-| | | |-|-|-| | \-\--
dokumentace |--latex \--MobileWaiter.eap \--bakalarska_prace.pdf prototyp testovani zdrojovy_kod |--mobilni_aplkace |--webova_aplikace MobileWaiter.apk readme.txt
- Dokumantace bakalá°ské práce - Zdrojové soubory textu práce - Diagramy projektu - Text práce v PDF - Prototyp vytvo°ený v Balsamic Mockups - Vstupní soubory mtx - Zdrojové kódy - Zdrojový kód mobilní aplikace - Zdrojový kód webové aplikace - P°eloºená mobilní aplikace - Informace o obsahu DVD
37
38
KAPITOLA 7.
ZÁV
R
Literatura [1] VOGEL, L. Tutoriály pro tvorbu aplikací v OS Android.
http://www.vogella.de/android.html,
stav ze 18. 11. 2011.
[2] web:ab-x. Prodejce restaura£ních systém·.
http://www.ab-x.cz,
stav ze 29. 10. 2011.
[3] web:alza. prodejce elektroniky Alza.
http://www.alza.cz/,
stav ze 8. 5. 2012.
[4] web:balsamiq. Balsamiq Mockups.
http://balsamiq.com,
stav ze 5. 10. 2011.
[5] web:developer.android. Podpora pro vývoj aplikací v OS Android.
http://developer.android.com/index.html/,
stav z 5. 1. 2012.
[6] web:nette. Nette Framework.
http://nette.org,
stav ze 12. 4. 2012.
[7] web:novotny-atrima. Prodejce restaura£ních systém·.
http://www.novotny-atrima.com,
stav ze 29. 10. 2011.
39
