eské vysoké u ení technické v Praze Fakulta informa ních technologií Katedra softwarového inûen˝rství
Diplomová práce
Vedení projektu mobilních aplikací pro faktura ní systém a mobilní aplikace pro iOS Bc. Ji í Ostatnick˝
Vedoucí práce: Ing. Martin P lpitel 6. kv tna 2014
Pod kování Rád bych pod koval Ing. Martinovi P lpitlovi za nadöené vedení a také povzbuzování v únavn˝ch situacích. Díky také posílám Michalu Ku erovi, se kter˝m byla radost spolupracovat. Martin a Pavlovi díky za korekci textu. Y
Prohláöení Prohlaöuji, ûe jsem p edloûenou práci vypracoval(a) samostatn a ûe jsem uvedl(a) 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 . V souladu s ust. § 46 odst. 6 tohoto zákona tímto ud luji nev˝hradní oprávn ní (licenci) k uûití této své práce, a to v etn vöech po íta ov˝ch program , jeû jsou její sou ástí i p ílohou, a veökeré jejich dokumentace (dále souhrnn jen „Dílo“), a to vöem osobám, které si p ejí Dílo uûít. Tyto osoby jsou oprávn ny Dílo uûít jak˝mkoli zp sobem, kter˝ nesniûuje hodnotu Díla, a za jak˝mkoli ú elem (v etn uûití k v˝d le n˝m ú el m). Toto oprávn ní je asov , teritoriáln i mnoûstevn neomezené. Kaûdá osoba, která vyuûije v˝öe uvedenou licenci, se vöak zavazuje ud lit ke kaûdému dílu, které vznikne (by jen z ásti) na základ Díla, úpravou Díla, spojením Díla s jin˝m dílem, za azením Díla do díla souborného i zpracováním Díla (v etn p ekladu), licenci alespo ve v˝öe uvedeném rozsahu a zárove zp ístupnit zdrojov˝ kód takového díla alespo srovnateln˝m zp sobem a ve srovnatelném rozsahu, jako je zp ístupn n zdrojov˝ kód Díla.
V Praze dne 6. kv tna 2014
.....................
eské vysoké u ení technické v Praze Fakulta informa ních technologií c 2014 Ji í Ostatnick˝. 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 Ostatnick˝, Ji í. Vedení projektu mobilních aplikací pro faktura ní systém a mobilní aplikace pro iOS. Diplomová práce. Praha: eské vysoké u ení technické v Praze, Fakulta informa ních technologií, 2014.
Abstrakt Tato práce popisuje proces v˝voje iPhone aplikace pro faktura ní systém Fakturoid — od anal˝zy p es návrh uûivatelského rozhraní a implementaci po testování. Sou ástí práce je také rozbor tvorby formulá a spolupráce na Android verzi. Klí ová slova mobilní faktura ní aplikace, iPhone, iOS, anal˝za, návrh, wireframes, API, implementace, realizace formulá , RestKit, jednotkové testování, Sinatra, uûivatelské testování, vedení t˝mu, spolupráce
Abstract This Master Thesis aims at development process of the iPhone invoice application named Fakturoid — from analysis through design of wireframes and implementation up to testing. The paper also includes analysis how to make forms and collaboration on the Android version. Keywords mobile invoice app, iPhone, iOS, analysis, design, wireframes, API, implementation, realization of forms, RestKit, unit testing, Sinatra, user testing, management team, cooperation
ix
Obsah Úvod
1
1 Anal˝za a cíl práce 1.1 Poûadavky na implementovan˝ produkt . . . . . . . . . . . . . 1.2 Seznam úloh podle skupin . . . . . . . . . . . . . . . . . . . . .
3 3 4
2 Reöeröe 2.1 iDoklad . . . 2.2 „Faktury“ . . 2.3 Zoho Invoice 2.4 Turbo Invoice 2.5 Shrnutí . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
7 7 8 8 9 11
3 Návrh designu 3.1 Transformace obsahu . . . . . . . . . 3.2 Formulá e . . . . . . . . . . . . . . . 3.3 Sekce Já a r zná nastavení . . . . . 3.4 P idání nové poloûky faktury . . . . 3.5 Heuristická evaluace . . . . . . . . . 3.6 Práce pro grafika . . . . . . . . . . . 3.7 Poûadavky na dopln ní funk nosti ve
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fakturoid
. . . . . . . . . . . . . . . . . . API
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
13 13 14 15 16 16 17 17
4 Realizace 4.1 RestKit . . . . . . . . . . . . . . . . 4.2 Struktura kódu . . . . . . . . . . . . 4.3 Formulá e . . . . . . . . . . . . . . . 4.4 eöené problémy . . . . . . . . . . . 4.5 Frameworky pro feedback a anal˝zu 4.6 Pouûité technologie pro v˝voj . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
19 19 21 26 32 37 38
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
5 Testování 41 5.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2 Akcepta ní testy . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.3 Uûivatelské testování . . . . . . . . . . . . . . . . . . . . . . . . 44 xi
6 Vedení t˝mu
47
Záv r
49
Literatura
51
A Seznam pouûit˝ch zkratek
55
B Dokumenty
57
C Wireframes
59
D Ukázky aplikace
81
E Materiály k uûivatelskému testování
83
F Obsah p iloûeného CD
85
xii
Seznam obrázk 1.1
Graf úloh aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 2.2 2.3 2.4
Ukázka Ukázka Ukázka Ukázka
. . . .
8 9 10 10
3.1 3.2
Rozloûení prvk faktura ního systému ve webové verzi . . . . . . . Ukázky eöení p echodu z jednoho textového formulá ového pole do druhého. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vzhled aplikace vytvo en˝ grafikem. . . . . . . . . . . . . . . . . .
13
3.3
aplikace aplikace aplikace aplikace
iDoklad . . . . Faktury . . . . Zoho Invoice . Turbo Invoice
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
4.1
Diagram t íd vztah mezi BusinessManagerem a t íd odvozen˝ch od Communicator v business vrstv . . . . . . . . . . . . . . . . . . 4.2 Diagram t íd základních obrazovek s funkcionalitou rozöi ující jejich moûnosti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Diagram balí k znázor ující strukturu t íd ve view vrstv . Diagram je zjednoduöen a obsahuje pouze doménu faktur. . . . . . . . 4.4 Diagram balí k znázor ující strukturu t íd v model vrstv . Diagram zobrazuje jenom vybrané entity. . . . . . . . . . . . . . . . . 4.5 Ukázka definice vzhledu ádku faktury ve Storyboardu. Zv˝razn n˝ je identifikátor ádku pro odkazování v kódu. . . . . . . . . . 4.6 Diagram balí k zobrazující d di nou strukturu formulá . . . . . 4.7 Sekven ní diagram zav ení formulá ového okna. . . . . . . . . . . . 4.8 Otev ené rychlé menu na poloûce v seznamu faktur. . . . . . . . . 4.9 M ení rychlosti komunikace se SDPY a HTTP – oblast s mal˝m zpoûd ním . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 M ení rychlosti komunikace se SDPY a HTTP – oblast s vysok˝m zpoûd ním . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1
6
15 18 23 24 25 26 29 31 31 34 36 37
Schéma komunikace v t˝mu . . . . . . . . . . . . . . . . . . . . . .
48
B.1 Schéma transformace obsahu . . . . . . . . . . . . . . . . . . . . .
58
xiii
D.1 Formulá faktury, odb ratel není z eské republiky, uûivateli se proto zobrazila informa ní hláöka. . . . . . . . . . . . . . . . . . .
xiv
82
Úvod Dneöním trendem v softwarovém inûen˝rství je p esun aplikací z velk˝ch obrazovek stolních monitor na displeje mobilních za ízení. Uûivatelé to vyûadují, zrychlí jim to práci, mají své aplikace neustále dostupné a mohou je pouûívat tém kdykoliv. P íkladem m ûe b˝t p ítomnost bankovních aplikací v mobilním prost edí. Tato práce se zab˝vá tvorbou mobilní verze faktura ního systému Fakturoid1 . Jedná se o webovou aplikaci poskytující uûivatel m moûnost správy faktur (vytvá ení, odesílání, kontrola obrûené platby. . . ). Zp sob v˝voje mobilní aplikace se v principu podobá tvorb webové nebo desktopové aplikace. Má své ale specifické problémy. Jedním ze specifick˝ch úkol této domény je návrh pouûitelného uûivatelského prost edí fungující na malém prostoru mobilní obrazovky. Mal˝ prostor nutí v˝vojá e k zobrazování omezeného po tu grafick˝ch prvk . V˝vojá i také musí mít na pam ti, ûe uûivatelé by m li b˝t schopni provést akce v co nejmenöím po tu krok . Nejrozöí en jöími mobilními opera ními systémy jsou Android a iOS [1], proto i projekt mobilních aplikací pro Fakturoid je cílen˝ na tyto dv platformy. Tato práce se zab˝vá v˝vojem aplikace pro opera ní systém iOS a spoluprací na v˝voji verze pro Android. Text popisuje cel˝ proces v˝voje, od anal˝zy poûadavk p es reöeröi podobn˝ch aplikací, návrh vzhledu obrazovek, implementaci aû po akcepta ní a uûivatelské testování.
Y
1
www.fakturoid.cz
1
Kapitola
Anal˝za a cíl práce Nazna enou práci v úvodu jsem dostal na starost já, a to ve verzi pro iOS. M˝m hlavním cílem je tedy vytvo it Fakturoid aplikaci na p ístroje iPhone.2 K tomu se váûou práce, které jsou m˝m cílem: • • • •
Navrhnutí wireframes pro iPhone Prostudování Fakturoid API Samotné vytvo ení aplikace Spolupráce s v˝vojá em Android verze
Neû se pustím do návrhu wireframes, musím zanalyzovat, které funkce by m la aplikace obsahovat.
1.1
Poûadavky na implementovan˝ produkt
Ze zadání není pot eba zkoumat innosti uûivatel , tak jak by se to d lalo, kdybych vytvá el úpln nov˝ produkt. Jelikoû uû existuje webová verze faktura ního systému, tak softwarové poûadavky jsou jiû dány.
Funk ní poûadavky • • • • • • •
Registrace P ihláöení P ehled vyfakturovan˝ch pen z za ur ité asové období P ehled posledních d leûit˝ch zpráv P ehled posledních faktur Zobrazení seznamu vöech faktur a podle filtru Vytvo ení nové faktury
2 Mluvím pouze o mobilních za ízení iPhone. Tabletová verze pro iPad v prvním verzi aplikace nebyla uvaûována.
3
1
1. Anal˝za a cíl práce • Zobrazení vybrané fakturu z listu – – – – – – –
Zobrazení faktury jak bude vypadat p i tisku Duplikování faktury Stornování faktury Smazání faktury Poslání faktury na e-mail Ozna ení faktury jako zaplacená Volání kontaktu p idruûené k faktu e
• Editování faktury • Zobrazení seznamu kontakt • azení kontakt podle abecedy • Zobrazení vybraného kontaktu
– Volání kontaktu – Vystavení faktury s tímto kontaktem
• Vytvo ení nového kontaktu
– P edvypln ní formulá e daty z ARES podle I O
• Editování kontaktu
– Aktualizování formulá e daty z ARES podle I O
• Synchronizace dat se serverem • Zobrazení informací o p ihláöeném uûivateli • Odhláöení
Nefunk ní poûadavky • • • •
1.2
Aplikace pob ûí na iOS 6.1 a vyööím Aplikace bude nativní, napsána v jazyce Objective-C Aplikace bude mít moderní flat design stylu iOS 7 Aplikaci musí mít plynulé uûivatelské rozhraní (animace v UI se nesmí viditeln zasekávat)
Seznam úloh podle skupin
Funk ní poûadavky jsem rozd lil do skupin podle toho, jak spolu úkoly souvisejí. Tyto skupiny funkcí pak budou zobrazené na stejné obrazovce nebo budou mít vzdálenost od sebe maximáln p es jeden obrazovkov˝ p echod. Legenda k následujícímu seznamu: poloûky zv˝razn né tu n˝m písmem jsou skupiny, ostatní jsou úkoly aplikace.
4
1.2. Seznam úloh podle skupin • P ihláöení do aplikace – Registruj – P ihlaö
• P ehled
– Zobraz p ehled vyfakturovan˝ch pen z za ur ité asové období – Zobraz p ehled posledních d leûit˝ch zpráv – Zobraz p ehled posledních faktur
• Faktury – – – –
Zobraz faktury Nastav filtr zobrazení faktur Otev i detail faktury Vytvo fakturu
• Detail faktury – – – – – – – –
Generuj PDF Duplikuj Stornuj Smaû Poöli na email Ozna jako zaplacenou Volej Edituj
• Kontakty – – – – –
Zobraz kontakty Nastav azení kontakt Hledej kontakt Zobraz detail kontaktu Vytvo nov˝ kontakt
• Detail kontaktu – – – –
P idej do oblíben˝ch Volej Dopl data z ARES podle I O Vytvo fakturu s tímto kontaktem
• Nastavení
– Zobraz uûivatele – Odhlaö z aplikace
5
1. Anal˝za a cíl práce Cel˝ p edchozí seznam p ehledn zobrazuje graf na obrázku 1.1, kde obdélníky ozna ují budoucí obrazovky a modré ovály jednotlivé funkce. ern orámovan˝ obdélník ozna uje vstupní bod aplikace. äipky nazna ují p echody mezi obrazovkami na základ funkcí. Podle tohoto grafu pak snadno budu vytvá et návrh obrazovek.
Zobraz uživatele
Odhlaš
Přihlášení do aplikace
Registruj
Zobraz časové období
Přihlaš
Detail faktury
Zobraz faktury
Zobraz poslední zprávy
Zobraz poslední faktury
Přehled
Nastavení
Faktury
Kontakty
Nastav filtr zobrazení
Vytvoř fakturu
Zobraz kontakty
Vytvoř kontakt
Nastav řazení kontaktů
Hledej kontakt
Detail kontaktu
Generuj PDF
Duplikuj
Stornuj
Smaž
Pošli na email
Označ jako zaplacená
Volej
Edituj
Přidej do oblíbených
Volej
Doplň data z ARES
Vytvoř fakturu s kontaktem
Obrázek 1.1: Graf úloh aplikace
Y 6
Kapitola
Reöeröe Neû za nu navrhovat první papírové návrhy aplikace, prostuduji, jak úkol vytvá ení faktur eöí ostatní. Mohu se tím p iu it, jak na m aplikace p sobí, také zjistím, eho se vyvarovat, a mohu najít n co, ím se inspirovat. Procházel jsem na App Store3 aplikace pod klí ov˝mi slovy faktury a invoices. V následujících odstavcích uvádím nejzajímav jöí eské a zahrani ní aplikace pro správu faktur.
2.1
iDoklad
iDoklad je název velmi povedeného webového faktura ního systému. P ívlastek „poveden˝“ vöak uû nelze p isoudit její mobilní verzi na iOS. Grafika je nep íjemná na pohled, ikony tla ítek v aplikaci vypadají, jako kdyby byly vyst iûeny z n jakého známého opera ního systému. Toto by se dalo p i pouûívání p ehlédnout, kdyby vöak aplikace zachovávala základní pravidla rozvrûení prvk v uûivatelském rozhraní systému iOS. Nap . funkce vytvo it fakturu je reprezentována jako tab ve spodní naviga ní liöt ur ené pro p epínání obrazovek; p ístupové öipky na poloûkách v seznamu zna í detail poloûky, kde ûádná moûnost detailu není; místo obrazovky seznamu pro v˝b r odb ratele se zde pouûívá UIPickerView (viz obrázek 2.1b). Naöel jsem tu i funkce, které se mi líbily. iDoklad má moûnost definování ceníku, tj. p eddefinovan˝ch poloûek, které budete asto fakturovat; nebo moûnost ov ování DI v rámci EU p ímo z aplikace, takûe uûivatel tuto informaci nemusí zjiö ovat na webu. To samé bych zmínil o kurzech m n. Z této aplikace si jako pou ení odnáöím, ûe Fakturoid aplikace musí mít p íjemnou sou asnou grafiku a prvky v uûivatelském rozhraní musí b˝t na místech, kde by je uûivatel znal˝ iOS hledal. 3 App Store je internetov˝ obchod aplikací dostupn˝ pouze z p ístroj pouûívající opera ní systém iOS.
7
2
2. Reöeröe
(a) Seznam faktur
(b) V˝b r dodavatele
Obrázek 2.1: Ukázka aplikace iDoklad
2.2
„Faktury“
Druhá eská aplikace nesla pouh˝ název Faktury. Funguje bez problém a dob e se pouûívá. Ale je tu jeden velk˝ rozdíl oproti Fakturoid systému. Faktury nemají webovou verzi, takûe uûivatel je odkázan˝ pouze na mobilní sv t. A to není dobré eöení, protoûe mobilní aplikace na faktury kv li zmenöenému pohodlí nebude vyuûívaná p es cel˝ den.
2.3
Zoho Invoice
V Zoho Invoice aplikaci jsem se cítil, a koliv na m svítil radostn˝ flat design, rozmrzele. Nemohl jsem se totiû v aplikaci zorientovat. P i prvním spuöt ní m aplikace nucen provedla nastavením m˝ch faktura ních údaj a potom m uvedla do p ehledu, kter˝ byl prázdn˝. Poté jsem sice objevil postranní menu (o patnácti poloûkách!), ale p echod mezi sekcemi byl práv kv li automatickému zavírání postranního menu otravn˝. Bohuûel, tímto moje öpatná nálada z negativního uûivatelského proûitku4 neskon ila. P i objevení formulá se nezobrazil kurzor na prvním editovatelném ádku. Tím jsem byl nucen se vûdycky chvíli trochu chaoticky rozhlíûet, 4 Ang. User Experience — Jde o pojem na zam ení na pot eby uûivatele, více nap . v [2]. Jak je vid t, zde mé pot eby jako uûivatele nebyly uspokojeny.
8
2.4. Turbo Invoice
(a) Seznam faktur
(b) Úprava produktu
Obrázek 2.2: Ukázka aplikace Faktury neû jsem zjistil, ûe mám za ít vypl ovat zrovna v daném míst . Samoz ejm , p i ast jöím pouûívání Zoho Invoice bych si jiû pamatoval, kde za ít editovat, ale musel bych d lat tento „klik“ navíc. To, co bylo v pomyslném bodování kv li mnoûství funkcí ztraceno, paradoxn zase bodování vylepöuje. Tato aplikace má totiû funkce na záznamy as , takûe pokud jste jako ûivnostník placen˝ od hodiny, které si sami po ítáte, nemusíte hledat jiné aplikace. Zoho vám vöechno toto zajistí.
2.4
Turbo Invoice
Aplikace Turbo Invoice m nejd íve elegantn provedla návodem, pak jsem se p es nenucené nastavení dostal na p ehledné vstupní obrazovky. Oproti Zoho a iDokladu na m p sobila opravdu p ehledn a klidn . Z ejm za to mohlo menu, které bylo uspo ádáno v dolní ásti obrazovky jako tabbar, takûe jsem ho m l po ád na o ích. Krom sekcí faktury a kontakty zde byla i sekce pro produkty, kde se nadefinovaly poloûky pro faktury. Tuto sekci má sice i iDoklad, ale v Turbo p sobí více odleh en . Nev˝hodou bylo, ûe vytvá ení faktury nutí vytvo it produkt, kter˝ uû bude nastálo v seznamu, dokud ho neodstraním. To mi p ipadá zbyte né. Faktury jsou viditeln barevn ozna ené podle stavu. Z horního menu lze vypozorovat, ûe v Zoho se inspirovali od Turbo Invoice nebo naopak, protoûe pouûili stejn neobvykl˝ styl filtrace faktur. 9
2. Reöeröe
(a) Hlavní menu
(b) Filtrace zobrazovan˝ch faktur
Obrázek 2.3: Ukázka aplikace Zoho Invoice
(a) Seznam faktur
(b) Formulá nové faktury
Obrázek 2.4: Ukázka aplikace Turbo Invoice 10
2.5. Shrnutí
2.5
Shrnutí
Z celé reöeröe si odnáöím tyto poznámky ke tvorb aplikace: • nechávat co nejvíce informací uûivateli na o ích (to potvrzuje pravdivost Heuristické evaluace, viz kapitola 3.5) — a koliv je to na mal˝ch obrazovkách mobilních p ístroj nelehk˝ úkol; • po zobrazení formulá e zobrazit kurzor na jeho první poloûce; • mít v aplikaci p íjemnou sou asnou grafiku. Dodrûením tohoto seznamu bude Fakturoid aplikace drûet krok s konkure ními aplikacemi, ne-li bude p ed nimi.
Y
11
Kapitola
Návrh designu 3.1
Transformace obsahu
Obrazovky mobilních za ízení jsou malé. To je nejzásadn jöí v c, na kterou je nutno pamatovat, kdyû se vytvá í obsah do mobilního za ízení. V této práci nevym˝ölím novou funk nost, v podstat jde o istou transformaci webové aplikace do iOS prost edí. Poj me se na tuto transformaci podívat. Webová verze faktura ního systému Fakturoid se skládá ze t í hlavních prvk (viz obrázek 3.1): 1. Menu 2. Vedlejöí menu 3. Obsah
Obrázek 3.1: Rozloûení prvk faktura ního systému ve webové verzi 13
3
3. Návrh designu Menu o maximáln p ti prvcích v systému iOS reprezentuje spodní liöta s tla ítky pojmenovan˝mi jako taby. To se krásn hodí pro naöe hlavní menu. P esunul jsem ho tam. Ve webové verzi je obsah s vedlejöím menu postaven vedle sebe. To se pro úzké mobily nehodí, musí leûet nad sebou. Dalöí v c, co stojí za úvahu, je, ûe toto podmenu nebude vyuûívané po ád, uûivatel se jde podívat hlavn na obsah. Skryl jsem tedy menu pod horní naviga ní liötu. Takto to asto d lá Apple5 ve sv˝ch aplikacích, kdyû chce schovat pole pro hledání poloûek (search bar), a tím zachová istotu grafického designu. P íkladem m ûe b˝t aplikace iBooks.6 Dále si lze vöimnout, ûe vedlejöí menu vûdy obsahuje jednu zv˝razn nou poloûku, a to tu první. Tato poloûka nese funkci jako p idat fakturu nebo kontakt, upravit fakturu nebo kontakt. V iOS tyto funkce mívají místo na pravé stran horní naviga ní liöty. P esunul jsem v návrhu první poloûku vedlejöího menu sem. Tento m j p esun podporuje zv˝razn ní první poloûky ve webové verzi — coû zna í, ûe je nejvíce vyuûívaná. Schéma celé transformace si m ûete prohlédnout na obrázku B.1, kter˝ to jasn zachycuje.
3.2
Formulá e
Hlavním prvkem faktura ního systému je formulá . Jak uûivateli zajistit pohodlí p i vypl ování jednotliv˝ch ádk formulá e, tak aby nemusel provád t nadbyte né úkony? Procházel jsem aplikace, které sám pouûívám, a vöímal si, jak to eöí. Ve v˝sledku jsem naöel pouze dv verze eöení. První je p idání naviga ních tla ítek nad klávesnici; v druhém eöení je pro p eskok do dalöího textového pole vyuûito dokon ovací tla ítko klávesnice leûící v pravém dolním rohu. Ukáûu to na p íkladech. První eöení pouûívá Basecamp iOS aplikace.7 Tato aplikace slouûí k t˝mové komunikaci a práv v této aplikaci se hojn vyskytují formulá ové vstupní textové pole. P echod z jednoho textového pole do druhého je eöen p idáním dvou naviga ních tla ítek p edchozí a dalöí nad klávesnici (obrázek 3.2). V˝vojá i pro to m li jasn˝ d vod. Protoûe textová pole jsou více ádková, pravé dolní tla ítko na klávesnici zaujalo funkci enteru. P idanou liötu nad klávesnicí lze také nalézt p i vypl ování formulá ov˝ch prvk v Safari8 , kdyû si prohlíûíte webov˝ obsah. Toto eöení se mi z designového pohledu nelíbilo. Nastavená liöta neefektivn zabírala cenné místo na malé obrazovce. 5
Tv rce opera ního systému iOS a „chytr˝ch“ p ístroj fungující s tímto systémem, www.apple.com 6 Dostupné na App Store, itunes.apple.com/cz/app/ibooks/id364709193?mt=8 7 Dostupná na App Store: itunes.apple.com/cz/app/basecamp-official-app/id599139477?mt=8 8 Webov˝ prohlíûe v opera ním systému iOS.
14
3.3. Sekce Já a r zná nastavení
(a) Basecamp
(b) Messenger
Obrázek 3.2: Ukázky eöení p echodu z jednoho textového formulá ového pole do druhého.
Messenger iOS App9 od Facebooku fungoval p esn , jak jsem hledal. V jeho p ihlaöovací obrazovce po vypln ní emailu sta ilo zmá knout tla ítko Dalöí v pravém dolním rohu klávesnice a hned jsem mohl vyplnit heslo (obrázek 3.2). Ve Fakturoidu více ádkové textové pole s moûností vloûit nov˝ ádek nebyl plánovan˝, je tedy z ejmé jaké eöení jsem pouûil.
3.3
Sekce Já a r zná nastavení
Webová verze má spousty nastavení jako nap . v˝chozí hodnoty vkládané do nové faktury, p edp ipravené texty pro emailové upozorn ní pro klienta nebo vlastní informace o uûivateli. Pro nedat moûnost zm ny t chto r zn˝ch nastavení do mobilní aplikace? Odpov dí jsou slova Lukáöe Konarovského, jednoho ze dvou konstruktér Fakturoidu, vy ená p i komunikování na Basecampu (více o komunikování v t˝mu v kapitole 6): „Jsme spíöe pro menöí sousto a ladit podle feedbacku od uûivatel a zkuöeností z provozu.“ 9
Dostupné na App Store: itunes.apple.com/cz/app/messenger/id454638411?mt=8
15
3. Návrh designu
3.4
P idání nové poloûky faktury
P idávání poloûky bude nejvíce opakovanou akcí ze vöech. Proto bylo nutné zajistit p idání ve velmi malém po tu krok . Pouûívám aplikaci Toshl Finance.10 Je to aplikace na domácí zapisování p íjm a v˝daj se statistikami a práv vloûení v˝daje mi hodn p ipomínalo naöe p idání poloûky. Avöak u Toshl Finance mi vadilo, ûe kdyû vyplním sumu a tag (více nepot ebuji), klávesnice zajede, ale k tomu, abych v˝daj uloûil, jsem musel kliknout na tla ítko „Uloûit“. Zbyte n˝ jeden krok a jak m otravoval. Rozhodl jsem se tomuto rozmrzení ve Fakturoidu p edejít a navrhl jsem p idání poloûky takto: Na zaátku dostane fokus ádek „Popis“, na klávesnici místo Enteru bude „Dále“, po kliku na Dále fokus p esko í na ádek „Cena za MJ“ a na klávesnici bude nápis „P idat“. Po kliku na P idat zmizí okno a poloûka bude p idána. Tím bude p idávání velmi rychlé.
3.5
Heuristická evaluace
Pro ov ení uûivatelské p ív tivosti navrûeného prost edí jsem pouûil Heurestickou evaluaci [3]. Jde o ov ení, ûe kaûdá obrazovka spl uje seznam deseti bod , kter˝ sestavil z dlouholeté zkuöenosti p i testování uûivatelského rozhraní Jakob Nielsen. Dodrûení t chto deseti bod p ispívá ke spokojenosti uûivatele p i pouûívání aplikace. esk˝ p eklad jsem p evzal z [4]. Viditelnost stavu systému Systém by m l vûdy dát uûivateli v d t, co se práv odehrává. Spojení mezi systémem a reáln˝m sv tem Komunikace systému s uûivatelem by se m la odehrávat uûivatelsky p íjemn˝m zp sobem (srozumiteln˝ jazyk bez odborn˝ch termín ). Uûivatelská kontrola a svoboda Uûivatelé p i práci se systémem d lají chyby a pot ebují proto únikov˝ v˝chod pro návrat do p edchozího stavu. Konzistence a standardizace Uûivatelé by nem li b˝t nuceni p em˝ölet, jestli r zné termíny znamenají to stejné, proto se doporu uje dodrûovat obecné zásady. Prevence chyb Vyvarovat se chybov˝m hláöením bezpe n˝m designem, kter˝ bude preventivn p sobit proti problém m. 10 Toshl Finance dostupné na App Store: itunes.apple.com/cz/app/toshl-finance-savemoney-budget/id384083725?mt=8
16
3.6. Práce pro grafika Rozpoznání místo vzpomínání Uûivatel by nem l b˝t nucen vzpomínat si na provád ní operací v systému, instrukce by m ly b˝t v systému vûdy viditeln umíst ny. Flexibilní a efektivní pouûití Umoûn ní zrychlení práce se systémem pro pokro ilé uûivatele. Estetick˝ a minimalistick˝ design Bez nepot ebn˝ch informací. Pomoc uûivatel poznat, pochopit a vzpamatovat se z chyb Chybové hláöky by m ly b˝t uvád ny v p irozeném jazyce a m ly by navrhovat eöení. Nápov da a návody Vöechny informace se musí dát lehce vyhledat, nápov da by m la obsahovat postupy v krocích. Osobn bych nejvíce zd raznil t etí zásadu – Uûivatelská kontrola a svoboda –, která íká, ûe kdyû chybí na obrazovce tla ítko Zp t nebo Storno, uûivatele to hodn roz ílí. Toto testování jsem provedl osobn sám a chyby napravil podle zásad. (Tyto moje chyby se paradoxn t˝kaly jenom v˝öe zd razn né t etí zásady.)
3.6
Práce pro grafika
Po návrhu designu ve wireframech, které jsme p edtím ladili s tv rci Fakturoidu, jsem öel s vedoucím projektu Ing. Martinem P lpitelem zadat p ekreslení designu grafikovi. Ten na nás kladl velké mnoûství otázek, co se stane po kliknutí na to i ono. K osv tlení jeho dotaz jsem do wirefram p ekreslil a doplnil interakce. Tyto v˝sledné wireframy, které jsem tvo il v prototypovacím programu UXPin11 , m ûete vid t v p íloze C. V˝sledn˝ vzhled od grafika lze vid t na obrázku 3.3.
3.7
Poûadavky na dopln ní funk nosti ve Fakturoid API
Jedním z m˝ch úkol bylo nastudovat Fakturoid API v112 a sepsat seznam funkcí, které byly pro v˝voj aplikací pot eba a v první verzi API chyb ly. Tyto zm ny pak v˝vojá i Fakturoid API doimplementovali. API v1 poskytuje tyto sekce: 11 12
uxpin.com github.com/fakturoid/api/blob/v1/readme.md
17
3. Návrh designu
(a) Úvodní obrazovka – P ehled
(b) Seznam faktur
Obrázek 3.3: Vzhled aplikace vytvo en˝ grafikem.
• • • • • • •
Ú et Kontakty Faktury äablony Odesílání faktur emailem Události D leûité události
Do API v2 bylo nutné p idat následující: • • • • • • • •
13
P ihláöení Registrace Obrázek ke kontaktu Data pro p ehledové statistiky: uplynulé 3 m síce a rok 2013 Identifikátory u ádk faktury (nutné pro editaci) Podpora více ú t Nápov da dalöího ísla faktury Aktuální kurzy m n13
Y
eská národní banka poskytuje Kurzy devizového trhu v istém textovém souboru. Abychom nemuseli parsovat netypickou strukturu, dohodli jsme se s tv rci Fakturoidu, ûe nám budou kurzy m n poskytovat v API, protoûe oni sami uû takto kurzy m n získávají.
18
Kapitola
Realizace Nyní budu psát o tom, jak jsem realizoval navrûenou aplikaci v systému iOS. Nejd íve popíöu samotnou strukturu kódu, budu povídat o realizaci formulá e a nakonec zmíním eöení r zn˝ch problém , se kter˝mi jsem se setkal.
4.1
RestKit
Neû za nu popisovat vnit ní strukturu aplikace, zmíním se nejd íve o RestKit14 frameworku15 , kter˝ je pro funkcionalitu aplikace úst edním bodem a celá v˝sledná vytvo ená struktura se od n ho odvíjí. RestKit je Objective-C16 framework, kter˝ si klade za cíl, aby tvo ení interakce s RESTful17 webov˝mi sluûbami bylo p i v˝voji iOS aplikací jednoduché, snadné a rychlé. [6] Nap íklad, kdyû chci stáhnout p ísp vky z hlavní stránky Twitteru,18 následující kód ukazuje, jak se definuje mapování JSON19 obsahu na entity20 p ísp vku. V˝sledek spuöt ní takovéto aplikace s tímto kódem bude pole p ísp vk . 14
github.com/RestKit/RestKit Framework je softwarov˝ balí ek s hovotou funkcionalitou, kter˝ lze p idat k vlastnímu projektu a ve vyvíjeném kódu se na n j napojit a danou hotovou funkcionalitu vyuûívat, viz whatis.techtarget.com/definition/framework 16 Objective-C je primární programovací jazyk pro v˝voj softwaru OS X (desktopov˝ opera ní systém od Apple) a iOS (opera ní systém pro mobilní za ízení) — to je d vod, pro je v n m RestKit napsan˝. Objective-C je nadmnoûina programovacího jazyka C a poskytuje objektov orientovan˝ p ístup. [5] 17 Fakturoid mobilní aplikace získávají data ze vzdáleného serveru. P ístup a manipulace s daty zven í je umoûn n tazvan˝m API — Application Programming Interface — coû jsou implemenované funkce umoû ojící práv tyto vzdálené interakce s daty. RESTful je architektonick˝ styl íkající, jak by API m lo fungovat. Viz nap íklad www.ibm.com/developerworks/webservices/library/ws-restful/ 18 Sociální sít fungující v krátk˝ch zprávách, twitter.com 19 Formát pro v˝m nu dat, www.json.org/json-cz.htm 20 Entita je t ída, která uchovává pouze data a vlastní manupulaci s daty nechává na starost jin˝m zainteresovan˝m t ídám. 15
19
4
4. Realizace
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
18 19 20 21 22
23
24 25 26 27
// D e f i n i c e e n t i t y p í sp vku @ i n t e r f a c e RKTweet : NSObject @property ( nonatomic , copy ) NSNumber ú u s e r I D ; @property ( nonatomic , copy ) NSString ú username ; @property ( nonatomic , copy ) NSString ú t e x t ; @end // D e f i n i c e , j a k má R e s t K i t p í choz í JSON prvky namapovat na v l a s t n o s t i e n t i t y p í sp vku RKObjectMapping ú mapping = [ RKObjectMapping mappingForClass : [ RKTweet c l a s s ] ] ; [ mapping addAttributeMappingsFromDictionary :@{ @" u s e r . name " : @" username " , @" u s e r . i d " : @" u s e r I D " , @" t e x t " : @" t e x t " }]; // Vytvo en í HTTP po û adavku RKResponseDescriptor ú r e s p o n s e D e s c r i p t o r = [ RKResponseDescriptor r e s p o n s e D e s c r i p t o r W i t h M a p p i n g : mapping method : RKRequestMethodAny p a t h P a t t e r n : n i l keyPath : n i l statusCodes : n i l ] ; NSURL ú u r l = [NSURL URLWithString :@" h t t p : / / a p i . t w i t t e r . com/1/ statuses / public_timeline . json " ] ; NSURLRequest ú r e q u e s t = [ NSURLRequest requestWithURL : u r l ] ; // P o s l án í po û adavku na s e r v e r RKObjectRequestOperation ú o p e r a t i o n = [ [ RKObjectRequestOperation a l l o c ] i n i t W i t h R e q u e s t : r e q u e s t r e s p o n s e D e s c r i p t o r s :@[ r e s p o n s e D e s c r i p t o r ] ] ; [ operation setCompletionBlockWithSuccess : ^ ( RKObjectRequestOperation ú o p e r a t i o n , RKMappingResult ú result ){ // P í choz í v˝ s l e d n é p í sp vky NSLog (@"P í sp vky z ve e j n é t i m e l i n e : %@" , [ r e s u l t a r r a y ] ) ; } failure : nil ]; [ operation start ] ;
Ukázka pouûití RestKitu Z ukázky kódu lze post ehnout, ûe pouûívání RestKitu se skládá z 3 ástí: 1) vytvo ení entity; 2) definování mapování JSON obsahu do vlastností entity; 3) poslání REST poûadavku21 na server. Pro následující podkapitolu bych hlavn zd raznil t etí ást — na ádku 23 v ukázce pouûití RestKitu se v metod setCompletionBlockWithSuccess:failure: definují bloky kódu, které se mají provést p i úsp öném provedení poûadavku nebo kdyû se vrátí chybová odpov (typ HTTP kódu 4xx a 5xx). Zárove v t chto blocích lze získat informace o p ijaté odpov di na poûadavek a také v˝sledné namapované entitní objekty. 21 REST poûadavek m ûe b˝t jeden z v˝ tu typu HTTP poûadavk : GET, POST, PUT, DELETE, PATCH.
20
4.2. Struktura kódu
4.2
Struktura kódu
Jeöt p ed za átkem programování aplikace jsem mohl ur it, ûe ve v˝sledném kódu budou t ídy mající na starost pouze vykreslování obsahu; poté t ídy (entity), které ponesou pouze data (ty uû jsme vid li v p edchozí podkapitole) a t ídy, které budou tyto dv mnoûiny spojovat. Zvolil jsem tedy klasickou View-Business-Model strukturu. V˝vojá webov˝ch Java EE systém , Ing. Lukáö Rychteck˝, m navedl na myölenku, ûe View-Business-Model je dobré strukturovat pro kaûdou modelovou ást, nap . zvláö pro Invoice entitu a zvláö pro entitu Subject — vzniknou tím takzvané gadgety, které mohu jednoduöe zkopírovat z projektu do projektu. Jelikoû ned lám ûádnou webovou sluûbu, rozhodl jsem se z stat ve stávajícím jednotném View-Business-Model. Nyní nastala otázka: jak zpropagovat data odpov di serveru z business vrstvy aplikace do view vrstvy, aniû by si musel drûet v business vrstv odkazy na vöechny zainteresované instance t íd ve view. — Pevné drûení referencí by poruöilo pravidlo o malé provázanosti (ang. low coupling) z návrhov˝ch princip o zodpov dnosti t íd GRASP (více v [7]). — Na vy eöení propagování informací jsem pouûil návrhov˝ vzor Pozorovatel (ang. Observer Design Pattern [8]). Tento vzor íká, ûe t ída, která chce b˝t subjektem informována o ur it˝ch událostech, se u subjektu zaregistruje a také bude implementovat metody z rozhraní Observable. Aû dané události nastanou, subjekt na pozorovatelích zavolá pat i né metody. V pojmech jazyka Objective-C a v kontextu projektu Fakturoid to bude e eno takto: t ída, která chce b˝t notifikována o p íchozí odpov di ze serveru, a se zaregistruje u BusinessManageru (hlavní t ída business vrstvy) a a je konformní k protokolu BusinessManagerDelegate. Protokol definuje metodu didReceiveData:operation: pro success odpov di a pro error status kódy bude volána didFinishWithError:operation:, coû ukazuje následující úryvek kódu.
1 2 3 4 5 6 7
@ p r o t o c o l B u s i n e s s M a n a g e r D e l e g a t e
@optional ≠( v o i d ) d i d R e c e i v e D a t a : ( RKMappingResult ú ) mappingResult o p e r a t i o n : ( RKObjectRequestOperation ú ) o p e r a t i o n ; ≠( v o i d ) d i d F i n i s h W i t h E r r o r : ( NSError ú ) e r r o r o p e r a t i o n : ( RKObjectRequestOperation ú ) o p e r a t i o n ; @end
Protokol BusinessManagerDelegate
21
4. Realizace
Business vrstva Práv jsem zmínil t ídu BusinessManager. Ta funguje jako fasáda22 k funkcionalit business vrstvy. A koliv instance t ídy BusinessManager eöí mnoho funk nosti sama, n které zodpov dnosti deleguje na instance jin˝ch t íd. Proto vznikly t ídy APICommunicator a ARESCommunicator, potomci od t ídy Communicator, eöící komunikaci s Fakturoid API serverem, a s ARES23 serverem. A BusinessManager, kter˝ chce od t chto t íd, mající na starost komunikaci, získávat práv ty d leûité odpov di ze serveru, je sama pozorovatelem t chto t íd. Z toho vypl˝vá, ûe kaûdá t ída v business vrstv musí b˝t pozorovatelná. Aby implementace pozorovatelnosti byla napsána jenom na jednom míst , vznikla t ída BusinessWorker, od které vöechny t ídy, které cht jí notifikovat ostatní, d dí. Tyto vztahy ukazuje UML diagram t íd na obrázku 4.1. Diagram je v i realit pro p ehlednost o ezan˝ o vztahy, které s p edchozím v˝kladem nesouvisí, takûe se v kódu m ûete setkat jeöt s t ídami AllDownloadManager starající se o postupné posílání poûadavk na server a s t ídou Login, která zajiö uje v business logice p ihlaöování.
View vrstva Cocoa Touch24 je UI25 framework pro tvorbu softwarov˝ch program b ûící na iOS. Jeho podmnoûina UIKit framework umoû uje rychlou tvorbu obrazovek a p echody mezi nimi. Základ tvo í dva typy obrazovek: View Controller a Table View Controller. První typ obrazovky se v töinou vyuûije pro pevn dan˝ obsah (z návrh obrazovek v p íloze C lze usoudit, ûe to bude nap . p ihlaöovací obrazovka a také obrazovka „Já“ s informacemi o p ihláöeném uûivateli); druh˝ typ, jak uû sám název napovídá, se vyuûije pro p edem neznámé mnoûství dat, které se má zobrazit jako seznam — tato obrazovka bude vyuûita pro seznam faktur a pro seznam kontakt . Vöechny obrazovky, pro moji poûadovanou funk nost získávat informace z business vrsty, musí implementovat mechanismus pro zaregistrování k notifikacím, tzn. vöechny musí d dit od jednoho p edka, kter˝ tuto funkcionalitu bude eöit. Tato funkcionalita je veskrze jednoduchá. P i objevení obrazovky 22
Návrhov˝ vzor Fasáda (ang. Facade Design Pattern) mluví o jedné t íd , která funguje jako jednotn˝ vstupní bod a za sebou skr˝vá v töinou velké mnoûství dalöích t íd, kter˝m p edává zodpov dnost ud lat danou práci. [8] 23 ARES — Administrativní registr ekonomick˝ch subjekt je informa ní systém, kter˝ umoû uje vyhledávání nad ekonomick˝mi subjekty registrovan˝mi v eské republice (wwwinfo.mfcr.cz/ares/ares.html.cz). Vyhledat data o subjektu na základ I O (identifika ní íslo organizace) je jeden z funk ních poûadavk Fakturoid aplikace. 24 Cocoa Touch dokumentace je dostupná na iOS Developer Library: https: //developer.apple.com/library/ios/documentation/miscellaneous/conceptual/ iphoneostechoverview/iPhoneOSTechnologies/iPhoneOSTechnologies.html 25 UI – Uûivatelské rozhraní (ang. User Interface) — „spojení“ mezi uûivatelem a po ítaem. [9]
22
4.2. Struktura kódu
BusinessWorker NSMutableSet delegates
BusinessManager
+ (void)addDelegate: + (void)removeDelegate: + (void)notifyDelegatesOnMethod:onProtocol: + (void)notifyDelegatesOnMethod:onProtocol:withObject:
Communicator + (void)GETWithPath: + (void)POSTObject:withPath: + (void)PUTObject:withPath: + (void)PATCHObject:withPath: + (void)DELETEObject:withPath:
«Protocol» CommunicatorDelegate + (void)didReceiveData:operation: + (void)didFinishWithError:operation:
APICommunicator
ARESCommunicator
«notifies» «notifies»
Obrázek 4.1: Diagram t íd vztah mezi BusinessManagerem a t íd odvozen˝ch od Communicator v business vrstv . ji jednoduöe p idám do seznamu poslouchajících a p i „odchodu“ obrazovky ji ze seznamu odstraním. To ukazuje následující kód: 1 2 3 4 5 6 7 8 9 10
// Metoda v o l a n a systemem , kdyz j d e obrazovka do v i d i t e l n o s t i ≠ ( v o i d ) viewWillAppear : (BOOL) animated { [ s u p e r viewWillAppear : animated ] ; [ businessManager addDelegate : s e l f ] ; } // A metoda z a v o l a n a systemem p r i uplnem odchodu obrazovky ≠ ( v o i d ) vie wDidDis appe ar : (BOOL) animated { [ s u p e r view Did Disa p pe ar : animated ] ; [ businessManager removeDelegate : s e l f ] ; }
P ihláöení obrazovky k notifikacím z business vrstvy Tady jsem narazil na problém. Abych v kódu zachoval princip Don’t Repeat Yourself (znám˝ po zkratkou DRY) radící programátorovi, aby se vyhnul psaní kódu technikou copy-paste (více v [10]), cht l jsem tato volání, jak jsem v˝öe zmínil, umístit pouze do jedné základní t ídy. Jenomûe oba druhy obrazovek jsou jiné t ídy, první UIViewController, druhá UITableViewController. A protoûe Objective-C nepodporuje vícenásobné d d ní, musel jsem vytvo it základní t ídy dv : BaseViewController a BaseTableViewController. Ty budou 23
4. Realizace mít stejn˝ch t chto pár ádk . Navíc, kaûdá základní t ída si p i inicializaci získá odkaz na instanci business vrstvy, takûe nov definované obrazovky odvozené od základních budou mít pro práci k dispozici p ím˝ odkaz na business vrstvu. Seznamovému druhu obrazovky p ibyly dalöí poûadavky. Data získaná ze serveru ukládám do databáze. P ístup a manipulace s daty je v iOS eöen Core Data frameworkem26 a práv zm ny dat v databázi mohou obrazovky pozorovat pomocí NSFetchedResultsControlleru, kter˝ je sou ástí Core Data. Obrazovka si vytvo í instanci NSFetchedResultsControlleru, implementuje protokol27 NSFetchedResultsControllerDelegate a oznámí té instanci, ûe je delegát.28 Tím bude automaticky v d t, ûe data v persistentním úloûiöti se zm nila a m ûe podle toho obnovit sv j zobrazovan˝ obsah. Tato popsaná funkcionalita se hodí pro vöechny tabulkové obrazovky; vytvo il jsem tedy dalöí t ídu, na které vytvá ené obrazovky mohou stav t: FetchableTableViewController implementující práci s NSFetchedResultsControllerem a d dící od BaseTableViewController. Dalöí poûadavek na tabulkovou obrazovku byl ten, ûe kaûd˝ ádek seznamu, a uû faktur i kontakt , má mít skryté rychlé menu zobrazitelné p i ur itém gestu pojmenovaném jako swipe (více o tom v podkapitole 4.4). Funkcionalita pozorování persistentního úloûiöt by nem la b˝t pevn svázaná s rychl˝m menu, vytvo il jsem proto od FetchableTableViewController potomka SwipableTableViewController. Vöechna tato d d ní znázor uje diagram na obrázku 4.2.
UITableViewController
«Protocol» Datable
BaseTableViewController
«Protocol» BusinessManagerDelegate
FetchableTableViewController
«Protocol» NSFetchedResultsControllerDelegate
SwipableTableViewController
«Protocol» SWTableViewCellDelegate
Obrázek 4.2: Diagram t íd základních obrazovek s funkcionalitou rozöi ující jejich moûnosti. 26 Core Data dokumentace je dostupná na https://developer.apple.com/library/ios/ documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html 27 Protokol je obdoba pojmu interface v programovacím jazyce Java. 28 Delegát (ang. delegate), pojem hojn pouûívan˝ v prost edí iOS, má stejnou funkci jako pozorovatel v návrhovém vzoru Observer.
24
4.2. Struktura kódu Mám tedy p ipravené základní funkce obrazovek a nyní mohu tvo it p ímo obrazovky. V aplikaci je p t logick˝ch celk : p ehled, faktury, kontakty, informace o uûivateli a p ivítání. Celky o fakturách a kontaktech jsou jeöt rozd leny na detail a editaci. Obrázek 4.3 ukazuje na p íkladu faktury, jak t ídy obrazovek rozd lené do balí k vyuûívají základní t ídy. view.base
BaseTableViewController
view.invoices.detail
InvoiceDetailViewController
FetchableTableViewController view.forms
SwipableTableViewController
view.invoices.main
InvoicesViewController
Form
view.invoices.edit
NewEditInvoiceViewController
Obrázek 4.3: Diagram balí k znázor ující strukturu t íd ve view vrstv . Diagram je zjednoduöen a obsahuje pouze doménu faktur.
Model vrstva Model databáze aplikace a entity zrcadlí strukturu a data poskytovaná Fakturoid API v2 29 . Tak jako business vrstva je ovlivn ná RestKit frameworkem, i struktura model vrstvy vznikla na základ cizího vlivu. Tím vlivem je nástroj mogenerator + Xmo’d [11]. D vodem jeho nasazení je zrychlení propagace zm n databázového modelu do entitních t íd. A koliv Xcode30 umoû uje z „naklikaného“ modelu vytvo it dané t ídy, pozd jöí zm ny se jiû v definicích t íd neprojeví a programátor je musí provést sám. Takûe edituje zm ny na dvou místech. Mogenerator je program pro p íkazov˝ ádek, kter˝ pro dan˝ soubor .xcdatamodel (v n m je uloûena definice datového modelu) vygeneruje na kaûdou entitu dv t ídy. První t ída, _MyEntity, je ur ena v˝hradn k práci mogenerátoru a bude neustále p episována tak, aby z stala v synchronizaci s datov˝m 29
Fakturoid API je ve ejn p ístupné na adrese docs.fakturoid.apiary.io Xcode je IDE (v˝vojové prost edí) pro tvorbu OS X a iOS aplikací — developer.apple.com/xcode 30
25
4. Realizace modelem. Druhá t ída, MyEntity, potomek _MyEntity, p episována nebude a je ur ena pro programátorovu vlastní logiku nad entitou. Xmo’d je pouh˝ plugin pro integraci mogenerátoru do Xcode. [12] Druhou generovanou t ídu ur enou pro vlastní logiku jsem vyuûil k nesení definic mapování dat z JSON struktury na prom nné entity pot ebné k funkcionalit RestKitu. Povinnost poskytovat definice ur uje protokol MapableObjectProtocol, kter˝ je implementován abstraktní t ídou MapableObject. Tato abstraktní t ída je rodi em vöech entitních t íd.
model.mogenerated «Abstract» _MapableObject
_Invoice
_Subject
_Account
_Event
Subject
Account
Event
model.human
Invoice
«Abstract» MapableObject «Protocol» MapableObjectProtocol
Obrázek 4.4: Diagram balí k znázor ující strukturu t íd v model vrstv . Diagram zobrazuje jenom vybrané entity. V model vrstv jsou také umíst ny datové t ídy podobné entitám, ale nemají ekvivalent v databázovém modelu. Tyto datové t ídy d dí od NoEntityMapableObject, která také implementuje MapableObjectProtocol. Jsou vyuûívány k reprezentaci dat z p íchozích JSON odpov dí od serveru, a protoûe od nich nechci persistentní uloûení, jsou po zpracování zahozeny jako klasické objekty. P íkladem je t ída ApiToken, která mi p inese token pro komunikaci s Fakturoid serverem nebo t ída ARESSubject, která reprezentuje subjekt získan˝ na základ I O z ARES serveru.
4.3
Formulá e
Základním prvkem Fakturoid aplikace je formulá . Je to d leûit˝ nástroj pro tvorbu obsahu a pro získávání dat od uûivatele. Ve Fakturoid aplikaci je for26
4.3. Formulá e mulá vyuûit pro tvorbu a úpravu faktury i kontaktu. Uû v za átcích návrhu obrazovek mi bylo jasné, ûe formulá bude vyûadovat velmi abstraktní konstrukci, aby bylo moûné jednoduöe upravovat formulá faktury podle nastavení vstupních parametr . Na konferenci mDevCamp 201331 senior iOS developer Juraj urech z firmy Inmite p edvád l jejich firemní knihovnu na tvorbu formulá [13]. V JSON souboru definovali obsah, v Nib souborech32 vzhled jednotliv˝ch ádk a t ída odvozená od UIViewController se starala o business logiku. Juraj urech tvrdil, ûe d vod, pro toto krásné a elegantní eöení neuvolní jako otev en˝ kód, je nutnost podpory pro ostatní v˝vojá e, emuû se necht li zavázat. Rozhodl jsem se jejich framework získat i s absencí podpory. Po pár v el˝ch emailech jsem ale framework k dispozici nedostal. Rozhodl jsem se eöení na tvorbu formulá napsat sám. Z inmitovského frameworku jsem si odnesl, ûe nejlepöí eöení je odd lit od sebe vzhled, strukturu a chování.
Konfigurace ádku Necht l jsem hned od za átku psát velk˝ framework, za al jsem tedy po mal˝ch krocích. Nejd íve jsem ádky formulá e konfiguroval p es NSArray (pole prvk ). Pro kaûdou vlastnost jsem m l vlastní pole, kde se na daném indexu uchovávala hodnota pro dan˝ ádek. To ale záhy bylo neúnosné, protoûe to neumoû ovalo elegantní definice v˝chozích hodnot. Nap . kdyû jsem cht l nastavit flag pouze prost ednímu ádku tabulky, musel jsem ru n pro ostatní napsat prázdnou hodnotu. Musel jsem tedy refaktorovat strukturu z více polí na pouze jedno pole, které by neslo konfigura ní objekty. Ty uchovávaly jednotlivá nastavení pro kaûd˝ ádek zvláö . A v objektu uû bylo snadné definovat defaultní hodnoty. T ída FormCellConfiger, která nese konfiguraci ádku, vypadá následnovn : 1 2 3 4 5 6 7 8 9 10 11 12 13
@ i n t e r f a c e F o r m C e l l C o n f i g e r : NSObject // / T i t u l e k @property ( nonatomic , s t r o n g ) NSString ú t i t l e ; // / Ná pov da pro vstupn í p o l e @property ( nonatomic , s t r o n g ) NSString ú p l a c e h o l d e r ; // / I d e n t i f i k á t o r v z h l e d u ádku @property ( nonatomic , s t r o n g ) NSString ú c e l l I d e n t i f i e r ; // / Ná zev datov é prom nn é , k t e r á s e má z e n t i t y namapovat na vstupn í p o l e @property ( nonatomic , s t r o n g ) NSString ú mappingValue ; // / Flag pro ur en í f u n k c e ádku , nap . t l a í tko nebo p ep í na @property ( nonatomic ) N S I n t e g e r f l a g ; // / I d e n t i f i k á t o r p echodu na d a l ö í obrazovku @property ( nonatomic , s t r o n g ) NSString ú s e g u e I d e n t i f i e r ; 31 32
mDevCamp — konference pro mobilní v˝vojá e — mdevcamp.cz Nib je soubor pro grafické vytvá ení a úpravy uûivatelského rozhraní v Xcode. [14]
27
4. Realizace 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
@property ( nonatomic ) UIKeyboardType keyboardType ; @property ( nonatomic ) UIReturnKeyType returnKeyType ; @property ( nonatomic ) U I T e x t A u t o c a p i t a l i z a t i o n T y p e autocapitalizationType ; @property ( nonatomic ) CGFloat heightRow ; // / Rychl ˝ odkaz na prvn í d e f i n i c i v a l i d a c e @property ( nonatomic , s t r o n g ) F o r m C e l l V a l i d a t i o n ú v a l i d a t i o n ; // / P o l e v a l i d a c í @property ( nonatomic , s t r o n g ) NSMutableArray ú v a l i d a t i o n s ; // / Ur en í n e s t a n d a r d n í k l á v e s n i c e , nap . v˝b r datumu @property ( nonatomic , s t r o n g ) UIView ú inputView ; // / Ná zev o b j e k t u , k t e r ˝ n e s e i n f o r m a c i o p o z i c i ve f o r m u l á i @property ( nonatomic , s t r o n g ) NSString ú viewThatCaryTagFromIndexPath ; // / P o l e pro p i d án í dodate n˝ ch n a s t a v e n í @property ( nonatomic , s t r o n g ) NSMutableDictionary ú c r a t e ; // Dal ö í prom nn é pro v˝po e t v˝ ö ky ádku pro p í pad , kdy u û s e t e x t n e v e j d e do j e d n o á dkov é ho p r o s t o r u @property ( nonatomic ) CGFloat currentHeightRow ; @property ( nonatomic , weak ) UITextView ú textView ; @property ( nonatomic , s t r o n g ) NSString ú t e x t ; ≠ ( void ) addValidation : ( FormCellValidation ú) v a l i d a t i o n ; @end
Definice t ídy FormCellConfiger nesoucí konfiguraci ádku faktury. Následujících pár ádk ukazuje rychlé programové vytvo ení jednoho ádku faktury: 1 2 3 4 5 6
FormCellConfiger úa = [ [ FormCellConfiger a l l o c ] i n i t ] ; a . t i t l e = N S L o c a l i z e d S t r i n g (@" I n v o i c e number " , @" " ) ; a . mappingValue = @" number " ; a . c e l l I d e n t i f i e r = @" F o r m C l a s s i c C e l l " ; a . keyboardType = UIKeyboardTypeNumbersAndPunctuation ; [ c o n f i g u r e s addObject : a ] ;
Programové vytvo ení jednoho ádku faktury.
Vzhled ádku Na rozdíl od inmitovského eöení jsem vzhled ádk nedefinoval v Nib souborech, ale protoûe jsem jiû vyuûíval Storyboard — coû je od iOS 5 alternativa k Nib m, která zceluje definice obrazovek a p echod na jedno místo — cht l jsem vyuûít jej. V p edchozích ukázkách kódu lze vid t cellIdentifier, v první ukázce na ádku 7 a v druhé ukázce na ádku 4. Tímto identifikátorem si ze Storyboardu vybírám vzhled ádku. P íklad vzhledu ádku ukazuje obrázek 4.5. Definování vzhledu ádku ve Storyboardu se mi ukázala jako öpatná volba, protoûe grafické obrazovky nelze od sebe nikterak d dit, i na sebe odkazovat. B hem v˝voje jsem se tedy za al pot˝kat s tímto problémem — kdyû jsem 28
4.3. Formulá e cht l ve více obrazovkách stejn˝ ádek typu FormClassicCell, musel jsem ho v kaûdé obrazovce definovat zvláö (stylem copy-paste). D vod nep epracování do definic na jednom míst podle vzoru Inmite je ten, ûe díky tomuto stylu se mi ve Storyboardu lépe orientovalo.
Obrázek 4.5: Ukázka definice vzhledu ádku faktury ve Storyboardu. Zv˝razn n˝ je identifikátor ádku pro odkazování v kódu.
Business logika Základní logiku zajiö uje t ída Form. Není ur ena k definici v˝sledného vzhledu, to budou d lat její potomci, ale poskytuje následující vlastnosti: • namapuje danou hodnotu z entity do formulá e a p i zm n od uûivatele dostane hodnotu zp t do entity; • postará se o zv töení v˝öky ádku p i velkém mnoûství zadaného textu; • pro vstupní pole pracující s datumem zajistí vytvo ení obrazovky pro v˝b r datumu; • pro vstupní pole pracující s íselnou hodnotou zajistí správné zobrazení v eském formátu (desetinná ísla lze zadávat s árkou); • zajistí objevení kurzoru v prvním ádku p i objevení obrazovky a p eskok kurzoru na dalöí ádek, kdyû je na klávesnici zvoleno tla ítko „dále“; • na základ definic validací zkontroluje kaûd˝ zadan˝ text; • p i öpatné validaci posune obrazovku na ádek, kde byla nalezena první chyba a zobrazí u n ho bublinu informující o typu chyby; • stejné informování o chyb provede po na tení chyby, která byla vrácena serverem. Neû vznikla tato rozsáhlá funk nost, musel jsem vy eöit, jak si pamatovat pozici daného ádku ve formulá i, protoûe ádky samy o sob tuto informaci nenesou. Vezm me si tento p íklad: vstupní pole dostalo fokus od uûivatele a abych v d l, která vlastnost entity bude editována, musel jsem získat odkaz 29
4. Realizace na dan˝ konfigura ní objekt, kter˝ zná mappingValue. Konfigurátor je ale schovan˝ pod n kter˝m indexem v poli cellConfigers. Kaûd˝ grafick˝ objekt v UIKit frameworku je potomkem t ídy UIView a ta má vlastnost tag typu integer slouûící k identifikaci view objekt v aplikaci (tag je defaultn nastaven na hodnotu 0). Pozice ádku poskytovaná UIKitem p i úvodní tvorb ádku je nesená objektem typu NSIndexPath a hodnota je v domén jedné tabulky jednozna ná. Rozhodl jsem se tedy obsah tohoto objektu namapovat do jedné íselné hodnoty — tímto by bylo moûno si informaci drûet ve vlastnosti tag jakéhokoliv zvoleného grafického objektu. NSIndexPath má v UIKit frameworku vlastnosti section a row udávající indexaci ádku v tabulce. Zakódoval jsem tyto dv hodnoty tak, ûe integer section jsem vynásobil hodnotou 1000 a následn jsem integer row k tomuto v˝sledku p i etl. Dekódování section je pak jednoduöe f loor(tag/1000) a row je tag ≠ (section ú 1000). Pro z ejmost uvádím kód, kter˝ lze najít ve t íd Common: 1 2 3 4 5 6 7 8 9 10 11 12
#d e f i n e SHIFTER 1000 + ( N S I n t e g e r ) tagFromIndexPath : ( NSIndexPath ú ) indexPath { N S I n t e g e r s e c t i o n = ( [ indexPath s e c t i o n ] + 1 ) ú SHIFTER ; N S I n t e g e r t a g = s e c t i o n + [ indexPath row ] ; return tag ; } + ( NSIndexPath ú ) indexPathFromTag : ( N S I n t e g e r ) t a g { N S I n t e g e r s e c t i o n = f l o o r ( t a g / SHIFTER) ; N S I n t e g e r row = t a g ≠ ( s e c t i o n ú SHIFTER) ; r e t u r n [ NSIndexPath indexPathForRow : row inSection : section ≠1]; }
Kódování NSIndexPath na tag a obrácen . Starost o vykreslování má základní t ída Form, její potomci mají starost o business logiku jednotlivého formulá e a manipulaci s oknem (v mém p ípad mám na mysli zav ení okna) eöí t ídy na obrázku 4.6 pojmenované s koncovkou ViewController. Jde o eöení problému, ûe okno v iOS m ûe b˝t zobrazeno zp sobem bu push nebo modal. A okno otev ené na push styl se zavírá jinou metodou neû okno otev ené stylem modal. Sekven ní diagram na obrázku 4.7 ukazuje pr b h zav ení okna, kde v metod closeFormViewController se pro modal zp sob volá: [ s e l f d i s m i s s V i e w C o n t r o l l e r A n i m a t e d : YES c o m p l e t i o n : n i l ] ;
Kdeûto pro push styl se volá: [ s e l f . n a v i g a t i o n C o n t r o l l e r popViewControllerAnimated : YES ] ;
30
4.3. Formulá e Je vid t, ûe oba kódy jsou zcela odliöné. Ale v˝öe popsan˝m rozd lením zodpov dnosti do t íd lze formulá vyuûít v jakémkoliv okn i obrazovce a formulá o tom v bec nemusí v d t. view.forms
Form
InvoiceForm
SubjectForm
view.invoices.edit
view.subjects.edit
NewEditInvoiceViewController
NewEditSubjectViewController
Obrázek 4.6: Diagram balí k zobrazující d di nou strukturu formulá .
:NewEditInvoiceViewController
:InvoiceForm
User cancel() cancelForm()
Příprava pro zavření formuláře
closeFormViewController() dismissViewController() Zavření okna
Obrázek 4.7: Sekven ní diagram zav ení formulá ového okna.
Validace Nejobsáhlejöí business logikou formulá e jsou validace. Z po átku jsem se spokojil pouze s kontrolou, zda je vstupní pole nutné vypl ovat. Tuto informaci nesl konfigura ní objekt ádku FormCellConfiger. P ed uloûením formulá e pak t ída Form pro vöechny konfigurátory zkontrolovala vypln ní vstupního pole. Ale záhy p iöla nutnost kontrolovat, ûe zadan˝ text je nap íklad íslo v eském formátu. Vznikla tedy t ída pro definici validace FormCellValidation, 31
4. Realizace jejíû objekty nese v poli jednotliv˝ konfigurátor ádku. Validátor umoû uje následující kontroly: • • • •
je/není povinnost vyplnit vstupní pole ov ení regulárního v˝razu kontrola ísla v i minimu kontrola ísla v i maximu
Nejsiln jöí na moûnostech vytvo ení validace je p idání regulárního v˝razu, coû umoû uje kontrolovat jak˝koliv formát textu. P i vytvá ení instance t ídy FormCellValidation je moûnost i vyplnit titulek, kter˝ bude zobrazen˝ v bublin informující o chyb . Celou validaci provádí t ída Form. Jenomûe to je pouze kontrola na vstupní texty. Narazil jsem i na pot ebu validovat stav celé faktury, a to v tom, zdali uûivatel vloûil do faktury n jaké fakturované poloûky. K procesu validace jsem nakonec p idal volání metody validateAdditionalConditions vracející typ BOOL. V p ípad poûadavku validace p ídavn˝ch kontrol lze tuto metodu implementovat v odvozen˝ch t ídách formulá e.
NewInvoice a EditInvoice, nebo NewEditInvoice? Cht l jsem rozd lit odpov dnost vytvá ení nové faktury a editaci faktury do r zn˝ch t íd se stejn˝m rodi em. Ale jelikoû tuto filozofii Storyboard v Xcodu (zatím33 ) nepodporuje — nelze tam odvozovat grafick˝ objekt od jiného —, musel jsem funkci vytvá ení a editaci nechat ve stejné t íd a rozdílnou funk nost rozliöovat isEdit booleanem, kter˝ byl nastaven na YES, kdyû p ed vytváením ViewControlleru byla nastavena prom nná invoice. Mohl jsem pouûít State Design Pattern [8], ale to mi p ipadalo jako jít s kanónem na vrabce, protoûe funk nost se liöí pouze v tom, jak jsou na po átku data na obrazovce vypln na a poté, jak jsou data ukládána. Název NewEdit. . . jsem takto zachoval, aby mi p i tení kódu bylo jasné, ûe d íve jsem to rozd loval, ale te je to slou ené v jedné t íd . Toto lze vid t i u formulá ádk faktury (NewEditLine. . . ) a u kontaktu (NewEditSubject. . . ).
4.4
eöené problémy
Nyní, kdyû jsem popsal strukturu kódu z globálního pohledu a vysv tlil fungování formulá , se zam ím na r zné lokální problémy, které jsem musel eöit a rozhodovat. 33 Neznám ûádné zdroje, které by íkaly, ûe tato funk nost se v Xcode n kdy objeví. Ale jelikoû neexistence této moûnosti m irituje, budou ji jist vyûadovat i dalöí v˝vojá i.
32
4.4.
eöené problémy
Jak tvo it formátovan˝ text? M l jsem za úkol zobrazovat „informa ní zprávy“ ve formátovaném textu (viz obrázek D.1 v p íloze), kter˝ je statick˝, v projektu se tedy jednou nadefinuje a z stane nezm n n dlouhou dobu. Moûnosti zobrazení formátovaného textu byly tyto: • UIWebview – HTML formát je znám˝ a snadn˝ pro editaci. UIWebview má ale nev˝hodu v tom, ûe neû se poprvé inicializuje její instance, trvá to v ádu jednotek vte in. • XIB soubor34 – Jednoduöe jako v n kterém známém textovém procesoru si naklikám v prvku UILabel vzhled textu. Já ale p et ûuji vöechny UILabel tím zp sobem, ûe jim nastavuji vlastní font, takûe mi veökeré formátování zmizí. A ve Storyboardu nelze nastavovat vlastní fonty. • NSAttributedString – Dalöí moûnost je v kódu nastavovat styl textu bold a italic v pevn definovan˝ch rozmezích jako atributy NSAttributedString, coû je systémová t ída na tvorbu formátovaného textu. Je to ale t ûkopádné, mnoho kódu na jeden textov˝ odstavec, kter˝ zbyte n bere programátorovi drahocenn˝ as. • TTTAttributedLabel35 je potomek UILabel a uleh uje p edchozí postup s NSAttributedString tím, ûe zabaluje n které úvodní definice, a tím zmenöuje a zp ehled uje mnoûství kódu. Hlavn umoû uje detekovat URL odkazy! Vít zem se stal TTTAttributedLabel. A koliv práce s ním stále není na „3 ádky“, je z uvedené reöeröe nejlepöí.
Jak tvo it r zné texty informa ní zprávy závisle na stavu faktury? Formátované informa ní zprávy z odstavce v˝öe m ly pro kaûd˝ stav faktury jin˝ text. Zm na textu ale vyûadovala vytvo ení celého view informa ní zprávy od za átku, protoûe se musel na íst text z HTML souboru, zparsovat, naformátovat poûadované ásti textu a vloûit do labelu. eöením je Builder Design Pattern [8]. P i vytvá ení informa ní zprávy, coû je ádek v tabulce formulá e, tento ádek jednoduöe zavolá „dej mi text“ na instanci creatora, kter˝ je definován v Builder Patternu. Creator zjistí stav faktury a podle tohoto stavu vytvo í instanci buildera. Nad tímto builderem zavolá metodu „dej mi text“, jejíû v˝sledek pak vrátí ádku informa ní zprávy. 34 35
XIB soubor je ekvivalent k NIB soubor m. Open source dostupn˝ na Githubu: github.com/mattt/TTTAttributedLabel
33
4. Realizace
Rychlá volba v seznamech Anglicky Swipe to more — to byl takov˝ poûadavek na urychlení práce s daty, aby se p i p ejetí prstu do strany na poloûce v seznamu faktury nebo kontakt objevilo rychlé menu. Mobilní aplikace této funk nosti hojn vyuûívají. Ale je to nestandardní v c, kterou Apple v iOS neimplementovala, proto na GitHubu vznikla spousta eöení [15]. Avöak, v dob za átku v˝voje mobilní verze Fakturoidu p iölo do sv ta v lét 2013 iOS 7 se sv˝m p epracovan˝m vzhledem [16]. Mazací systémové tla ítko v tabulkách z stalo, samoz ejm bylo redesignováno do flat designu, ale na koncefenci WWCD 201336 p edvád ná aplikace Mail.app zobrazila po swipnutí tla ítek více. Grafi tí designé i iOS aplikací za ali tento prvek dávat do sv˝ch aplikací, ale protoûe komponenty iOS 7 tuto moûnost neposkytovaly, tak se uû v pr b hu podzimu 2013 n kte í programáto i zam˝öleli nad tím, jak tuto funk nost vytvo it a sdíleli svá eöení na GitHubu. Ale protoûe v˝voj t chto eöení byl v po átku, nedávala uspokojující v˝sledky. SWTableViewCell 37 d lal na první pohled to, co jsem pot eboval, ale neskr˝val nabídku p i interakci s jin˝mi poloûkami. Dalöí moûností bylo eöení MSCMoreOptionTableViewCell 38 , které d lalo p esn to, co jsem vyûadoval. Ale jenom pro iOS 7. Fakturoid má b˝t cílen i na iOS 6. Vrátil jsem se k SWTableViewCell a skr˝vání poloûek naprogramoval sám. Projekt SWTableViewCell ale po ád rostl a tato funkcionalita se nakonec v pozd jöích verzích nakonec objevila.
Obrázek 4.8: Otev ené rychlé menu na poloûce v seznamu faktur.
P edávání dat mezi obrazovkami P edávání dat mezi obrazovkami není v iOS automatická v c. Nej ast jöí p ípad pouûití je v obrazovce seznamu sd lit následující obrazovce „zobraz de36
Apple Worldwide Developer Conference (WWDC) je konference pro v˝vojá e p edstavující poslední novinky v iOS a OS X. [17] 37 github.com/CEWendel/SWTableViewCell 38 github.com/scheinem/MSCMoreOptionTableViewCell
34
4.4.
eöené problémy
tail této poloûky“. äablona projektu v Xcode Master-Detail Application to eöí tak, ûe po vytvo ení instance následující obrazovky bu v metod tableView:didSelectRowAtIndexPath: nebo v prepareForSegue:sender: této instanci nastaví odkaz na vybranout entitu. Já tento zp sob cht l více generalizovat. Nastavovaná entita m ûe b˝t r zné t ídy, protoûe detailová obrazovka pracuje pouze s Invoice a jiné pouze se Subject entitou. A business proces p edávání entity jsem cht l mít pouze ve t íd FetchableTableViewController. eöením se stal protokol Datable, kter˝ implementovaly vöechny detailové obrazovky. 1 2 3
@ p r o t o c o l Datable ≠ ( v o i d ) s e t D a t a E n t i t y : ( id<M a p a b le O b j e c tP r o to co l >) d a t a E n t i t y ; @end
Datable protokol jenom íká, ûe obrazovka musí b˝t schopná p ijmout entitu. Poté, co objekt entity dostane v metod setDataEntity:, si ho sama zpracuje — nap . uloûí odkaz nebo vytvo í kopii objektu.
Unwind segue Pro tená e zajímající se o iOS v˝voj bych zmínil jeden typ nestandardního p echodu mezi obrazovkami — Unwind Segue. K uchování vytvo en˝ch obrazovek se pouûívá naviga ní zásobník [18]. Kaûdá nov vytvo ená obrazovka se uloûí na vrchol tohoto zásobníku a tím je zajiöt na funk nost návratu aplikace na p edchozí obrazovku – jednoduöe se na naviga ním kontroléru zavolá metoda popViewControllerAnimated:, zásobník funk nost o v˝znamu pop vykoná a následn do viditelnosti p ijde p edeölá obrazovka. Problém nastává, kdyû se chcete vrátit nap . o ty i obrazovky a ta tvrtá není první obrazovka v po adí (pro p esko ení na první obrazku sta í zavolat popToRootViewControllerAnimated: na naviga ním kontroleru) a zárove neznáte odkaz na cht nou obrazovku. A nebo chcete zahodit vöechny obrazovky ze zásobníku a p esko it do jiné linie obrazovek. eöením je vyuûití p echodu Unwind Segue, kter˝ ve Storyboardu nadefinujete na zdrojové obrazovce a v cílové implementujete metodu, která bude volána p ed vykonáním p echodu. Více nap íklad v [19]. V aplikaci jsem Unwind Segue vyuûil p i p epínání ú t uûivatele, kde bylo pro m nutné zahodit cel˝ zásobník obrazovek a za ít tvo it novou linii obrazovek zvona od p ihlaöovací obrazovky.
SPDY místo HTTP Kód aplikace je p ipaven˝ pro nahrazení HTTP za SPDY ( teno jako [spi:dy]). SPDY byl p vodn navrûen v Google jako experimentální nástupce za HTTP. Je to binární protokol (HTTP pouûívá normální textové znaky, které m ûe lov k bez problému íst), ale je pln kompatibilní s HTTP. SPDY si klade 35
4. Realizace za cíl zlepöit adu nedostatk HTTP a jedna z oblastí, kde má SPDY velk˝ potenciál, je vyuûití v mobilních za ízeních. Mobilní sít stále trpí vysokou latencí, takûe sníûení délky asu komunikace klient-server m ûe mít v˝razn˝ p ínos pro uûivatelskou p ív tivost aplikace. [20] A jaké je celkové zrychlení komunikace? Inûen˝ i ze spole nosti Twitter vyvíjejí knihovnu pod otev enou licencí CocoaSPDY, coû je implementace SPDY protokolu pro iOS a Mac OS X. Provád li m ení v oblastech, kde mobilní internet má vysoké i malé zpoûd ní. Celkov SPDY vykazoval o 30 % menöí zpoûd ní oproti komunikaci, která byla vedená p es protokol HTTP. Dalöím poznatkem z m ení je, ûe ím horöí jsou podmínky pro mobilní internet, tím více je SPDY rychlejöí neû HTTP. Lze to vid t p i porovnání obrázk 4.9 a 4.10 p evzat˝ch z [20]. Oblast s malým zpoždením 60 000 HTTP
SPDY
zpoždění [ms]
45 000
30 000
15 000
p50
p75
p95
p99
percentil (medián)
Obrázek 4.9: M ení rychlosti komunikace se SDPY a HTTP – oblast s mal˝m zpoûd ním Osa x je rozd lena na 50. percentil (medián), 75., 95. a 99. percentil z HTTP a SPDY poûadavk . Osa y reprezentuje zpoûd ní poûadavku v milisekundách. Fakturoid server má nasazen˝ nginx,39 kter˝ podporuje SPDY protokol, avöak pouze ve verzi 2. Framework CocoaSPDY pracuje s SPDY/3.1. Ve Fakturoid aplikaci komunikaci p es SPDY povolím, aû Fakturoid t˝m aktualizuje serverové knihovny. S tím se po ítá v horizontu n kolika m síc . 39
36
Nginx je softwarov˝ web server a reverzní proxy — nginx.org
4.5. Frameworky pro feedback a anal˝zu Oblast s vysokým zpoždením 60 000 HTTP
SPDY
zpoždění [ms]
45 000
30 000
15 000
p50
p75
p95
p99
percentil (medián)
Obrázek 4.10: M ení rychlosti komunikace se SDPY a HTTP – oblast s vysok˝m zpoûd ním
4.5
Frameworky pro feedback a anal˝zu
Do obou aplikací, jak do verze iOS, tak do Android, jsme p idali následující frameworky pro zp tnou vazbu, jak uûivatelé aplikaci vyuûívají a kde nám aplikace padá.
Flurry Flurry Analytics40 — sluûba na anal˝zu pouûívání mobilních aplikací pro vöechny platformy. Ve Flurry lze najít statistiky zobrazující kdy, kde a k˝m byla mobilní aplikace pouûívána. V aplikaci lze také nadefinovat kontrolní body (checkpoints) akcí, díky kter˝m m ûeme ve statistikách vid t, o kolik více uûivatelé pouûívají formulá faktury oproti formulá i kontaktu.
New Relic New Relic41 je monitorovací sluûba na HTTP poûadavky. Zaznamenává, v jak˝ch asech aplikace p istupovaly k API, jak dlouhou trvala odpov ze serveru API a kolikrát nastal v˝padek sít . 40 41
flurry.com/solutions/analytics newrelic.com
37
4. Realizace
Crashlytics Crashlytics42 je reportovací nástroj pád aplikace. A koliv i Flurry nebo dále zmín né TestFlight rovn û poskytují reporty pád aplikace, v Crashlytics se zam ují pouze na tuto doménu. To je d vod, pro jejich zpracování report je více propracované. [21] Crash reporty lze získat z App Store na itunesconnect.apple.com. To má ale dv nev˝hody. V töinou aplikaci na App Store posílá jin˝ subjekt, neû kter˝ ji vyvíjel (coû je i p ípad Fakturoid aplikace), takûe v˝vojá i k crash report m nemají p ím˝ p ístup. Druhá nev˝hoda je ta, ûe reporty z App Store jsou v syrové podob , v logu neuvidíte názvy metod, takûe musíte nejprve logy symbolizovat v i správnému buildu aplikace. Crashlytics zobrazí reporty jiû v hotové podob a navíc v reálném ase!
TestFlight TestFlight43 umoû uje posílat pre-release buildy iOS aplikací zainteresovan˝m osobám. Sice umí také kontrolovat checkpointy jako Flurry nebo sbírat crash reporty jako Crashlytics, ale jeho hlavním cílem je snadná distribuce tester m. P es TestFlight bylo moûné distribuovat i Android aplikace — takûe jiné platformní verze aplikace mohly b˝t distribuovány p es stejn˝ systém —, ale od 21. 3. 2014 TestFlight p estal Android podporovat. [22] D vodem z ejm bylo odkoupení TestFlight spole ností Apple. [23] Android developer Fakturoidu vöak od za átku v˝voje pouûíval TestFairy,44 jehoû hlavní v˝hoda oproti TestFlight je, ûe zaznamenává od testera video z jeho kaûdého pouûívání aplikace.
4.6
Pouûité technologie pro v˝voj
Struktura dat ve Fakturoid API je velmi rozsáhlá — objekty faktura i kontakt obsahují desítky vlastností. Vytvo ení modelové entity v projektu aplikace, to znamená p epsat vöechny vlastnosti do Objective-C t íd. Pouûití techniky copy-paste by p ineslo hodiny monotónního ma kání klávesov˝ch zkratek. Hledal jsem tedy n jaké aplikace, které by z JSON struktury ud laly Objective-C t ídu. A naöel jsem Objectify,45 kter˝ tuto práci umí. Ale stejn jsem si nakonec musel napsat vlastní generátor. Pot eboval jsem z JSONu generovat jeöt dva jiné kódy. První, vöechny názvy et zc JSON objektu jsem pot eboval dostat do objektu typu NSDictionary. Nap ., z následující JSON objektu faktury:
42
crashlytics.com testflightapp.com 44 testfairy.com 45 tigerbears.com/objectify 43
38
4.6. Pouûité technologie pro v˝voj
1
{
" bank_account " : " 123456/1234 " , " c i t y " : " Praha " , " c o u n t r y " : "CZ" , " c r e a t e d _ a t " : " 2013≠06≠18T14 : 1 5 : 0 0 + 0 2 : 0 0 " , " c u r r e n c y " : "CZK" /ú e t c . ú/
2 3 4 5 6 7 8
}
Ud lat object typu NSDictionary: 1
@{
2 3 4 5 6 7 8
};
@" bank_account " : @" bankAccount " , @" c i t y " : @" c i t y " , @" c o u n t r y " : @" c o u n t r y " , @" c r e a t e d _ a t " : @" c r e a t e d A t " , @" c u r r e n c y " : @" c u r r e n c y " // e t c .
Tato dictionary je pak pouûita k definici mapování JSON objektu na entitu modelu p i práci RestKitu. Druhá v c byla z toho samého JSONu vygenerovat expectations pro unit testy: 1
2
3
4
[ t e s t a d d E x p e c t a t i o n : [ RKPropertyMappingTestExpectation expectationWithSourceKeyPath :@" bank_account " d e s t i n a t i o n K e y P a t h :@" bankAccount " v a l u e :@" 123456/1234 " ] ] ; [ t e s t a d d E x p e c t a t i o n : [ RKPropertyMappingTestExpectation expectationWithSourceKeyPath :@" c i t y " d e s t i n a t i o n K e y P a t h :@" c i t y " v a l u e :@" Praha " ] ] ; [ t e s t a d d E x p e c t a t i o n : [ RKPropertyMappingTestExpectation expectationWithSourceKeyPath :@" c o u n t r y " d e s t i n a t i o n K e y P a t h : @" c o u n t r y " v a l u e :@"CZ" ] ] ; // e t c .
CocoaPods Jak je vid t z podkapitoly 4.5, vyuûívám v projektu mnoho knihoven t etích stran. P idat framework do projektu v XCode není akce na jeden krok. Musíte stáhnout knihovnu ze stránek v˝vojá e, rozbalit zip archív, p idat sloûku s knihovnou do projektu a v XCode nalinkovat binární soubor knihovny v Build Phases –> Link Binary With Libraries. A cel˝ tento proces musíte zopakovat, kdyû chcete knihovnu aktualizovat. Cel˝ tento proces se jeöt prodlouûí, máte-li nastavit frameworku n jaké flags pro linkování. 39
4. Realizace eöením je CocoaPods,46 kter˝ se o p idávání a aktualizace knihoven stará. V textovém souboru, pojmenovaném Podfile, nadefinujete platformu, pot ebné knihovny a jejich verze a pak jenom spustíte v p íkazové ádce pod install. CocoaPods zkontroluje závislosti, stáhne poûadované knihovny z vlastníkem definovaného úloûiöt a v˝vojá je m ûe hned vyuûívat. CocoaPods je jiû hodn rozöí en˝; vöechny knihovny, které jsem doposud hledal, jsem naöel.
Y
46
40
cocoapods.org
Kapitola
Testování V této kapitole popíöi, jak jsem po celou dobu v˝voje kontroloval správnost aplikace. Nakonec se budu zab˝vat akcepta ními testy, které definují, p i jaké funk nosti je první verze mobilních Fakturoid aplikací hotová.
5.1
Unit Testing
Podpora k jednotkov˝m test m47 — coû je testování samotn˝ch jednotliv˝ch metod t íd takové, ûe se zkoumá, zda metoda vrací o ekávan˝ v˝sledek, a to jak pro normální o ekávaná data, tak i pro hrani ní moûnosti — je dostupná p i v˝voji iOS aplikací jak ze strany Xcode, tak (pro m d leûité) ze strany RestKitu. Ve vytvo eném novém iOS projektu v Xcode 5 je jiû sou ástí sloûka ProjectNameTests, kde programátor vytvá í t ídy, ve kter˝ch píöe metody s názvem za ínající slovem test. Vöechny tyto metody Xcode detekuje a umoû uje, krom spuöt ní vöech test najednou jako celek, spustit test v jedné metod jednoduch˝m kliknutím na ikonu vedle ísla ádku na za átku dané metody, takûe v˝vojá m ûe snadno a rychle opakovat dan˝ test, dokud nenaprogramuje splnitelné eöení. RestKit zase p ichází s nabídkou otestovat správnost nadefinovaného mapování JSON objekt na entity pomocí tzv. fixtures. Fixture je soubor, do kterého zapíöu jeden moûn˝ JSON v˝sledek vrácen˝ jako odpov ze serveru. A poté v testové metod p idám restkitovému modulu na testování o ekávání takové, ûe na dané keypath o ekávám dan˝ textov˝ et zec. Pro p íklad n kter˝ch expectations m ûete nalistovat kapitolu 4.6. Tímto zp sobem jsem otestoval celou model vrstvu, takûe jsem si byl jist˝, ûe vöechny data z JSON objekt budou p eneseny do entit. Druhá v c, kterou bylo pot eba otestovat, bylo ov ení správného chování posílání poûadavk na API server. Tady jsem ale narazil na jeden problém. P íkazy v testech 47
Ang. Unit Tests
41
5
5. Testování se provád jí synchronn jeden za druh˝m, takûe kdyû jsem poslal na API server poûadavek a hned v druhém ádku testu kontroloval po et p íchozích JSON objekt , vûdycky jsem dostal v˝sledek nula — ûádné objekty nep iöly. Musel jsem tedy kontrolu o vte iny zpozdit. Vytvo il jsem metodu waitForCompletion:, kterou jsem volal vûdy po poslání poûadavku na server. Metoda waitForCompletion: ekala v nekone né while smy ce, dokud ze serveru nedorazila odpov , nebo nevypröel asov˝ limit. Jako konstantní as ukon ení jsem nastavil 30 sekund. Od tohoto vylepöení testy úsp ön procházely.
Sinatra Velk˝m usnadn ním pro testování aplikace jsem shledal pouûití lokálního serveru. Místo p ístupu na ve ejn˝ nebo testovací API server jsem se p ipojoval na adresu http://localhost:4567, kde b ûel lokální server se Sinatrou.48 Sinatra je DSL49 pro rychlé vytvo ení webov˝ch aplikací v Ruby. Tvorba odpov dí na url poûadavky je snadná, sta í do souboru myapp.rb napsat: 1 2 3 4
require ’ sinatra ’ g e t ’ / ’ do ’ H e l l o world ! ’ end
A server, po nainstalování gemu50 gem install sinatra a spuöt ní aplikace p íkazem ruby myapp.rb, nás bude na adrese http://localhost:4567 zdravit hláökou „Hello world!“ Pro mé pouûití, nap . vrácení seznamu kontakt , jsem zapsal do konfigura ního souboru ádky tak, jak je moûno vid t v ukázce kódu pod tímto odstavcem v metod za ínající na prvním ádku. Soubor subjects.json je stejn˝ fixture, o kterém jsem mluvil v souvislosti RestKit Unit Testing. A nyní se dostávám k hlavnímu d vodu vyuûití Sinatry na lokálním serveru. Úprava API serveru je pro m nep ípustná. Ale API server v n kter˝ch p ípadech vrací chybové status kódy, které není moûné reáln nasimulovat. Tímto p ípadem m ûe b˝t t eba offline mód API serveru, kdy ve vöech odpov dích vrací status kód 500 ; nebo p íchod öpatn zpracovatelné entity, mající za následek vrácení kódu 422, atd. Tyto p ípady jsem si podle API dokumentace nadefinoval a následné testování aplikace v i t mto p ípad m bylo uû jednoduché. 1 2 3
g e t ’ / s u b j e c t s . j s o n ’ do send_file File . join ( settings . public_folder , ’ subjects . json ’ ) end 48
sinatrarb.com Domain Specific Language je programovací jazyk navrûen˝ speciáln pro eöení problém specifické domény. Více v [24]. 50 Gem je p íkaz umoû ující interakci s balí kovacím systémem RubyGems. Tento systém poskytuje seznam Ruby aplikací nebo knihoven, které si m ûete stáhnout a nainstalovat. [25] 49
42
5.2. Akcepta ní testy 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
p o s t ’ /422 ’ do s e n d _ f i l e F i l e . j o i n ( s e t t i n g s . p u b l i c _ f o l d e r , ’ 422 Unprocessable Entity . json ’ ) , : s t a t u s => 422 end g e t ’ /503≠ s e r v i c e ≠u n a v a i l a b l e ’ do s t a t u s 503 end g e t ’ /500≠ o f f l i n e ’ do s t a t u s 500 end g e t ’ /402≠payment≠r e q u i r e d ’ do s t a t u s 402 end # etc .
5.2
Akcepta ní testy
K dohod ve spolupráci s vlastníky systému Fakturoid byly p iloûeny následující akcepta ní testy. Spln ní t chto test potvrzuje dokon ení v˝voje první verze mobilních aplikací systému Fakturoid. • Aplikace budou mít 4 základní sekce: – – – –
P ehled Faktury Kontakty Já
• Sekce P ehled – – – – –
Statistiky – za 3 m síce a za cel˝ aktuální rok Události – D leûité a Události D leûité jdou odökrtnout a zruöit odökrtnutí Ukázat 4 poslední události hned Faktury – Nejnov jöí a Pravidelné
• Sekce Faktury
– Jednoduch˝ list s moûností filtrovat faktury po splatnosti, vystavené, zaplacené – Faktura v seznamu obsahuje: 43
5. Testování ú
íslo, stav (Vystavená, Odeslaná, Po splatnosti, Zaplacená), odb ratele, datum související se stavem, ástku faktury bez DPH
• Sekce Kontakty
– Abecední seznam názv firem – Touch otev e detail kontaktu, kter˝ obsahuje: ú Název, adresu, email, telefon, I , DI ú Po et faktur, celkovou ástku vyfakturovanou klientovi bez DPH ú Touch po tu vystaven˝ch faktur otev e jejich seznam ú Akce detailu kontaktu: Fakturovat, volat ú Seznam událostí kontaktu
• Sekce Já
– Avatar p ihláöeného uûivatele a dalöí info (email, adresa atd.) – P epnout se do jiného ú tu, pokud mám – Odhláöení
• Faktura a zálohová faktura
– Aplikace umoûní vytvo it, prohlédnout a upravit fakturu a zálohovou fakturu (plnou a áste nou) – Akce na faktu e: Duplikovat, Stornovat (u faktury v p ípad neplátce DPH, jinak ne; u proformy jde storno vûdy), Smazat, Mail, Zaplatit / odzaplatit, Volat odb rateli – Faktura bude podporovat reûim p enesené DPH a kód pln ní pro faktury do EU
• Opravn˝ da ov˝ doklad
– Jen zobrazení, ne vytvo ení ani editace
• Registrace
– Z aplikace p jde vytvo it nov˝ ú et a
Vöechny tyto body akcepta ních test jsem implementoval — akcepta ní testy jsou pro aplikaci spln ny.
5.3
Uûivatelské testování
Na záv r jsem provedl testování na reáln˝ch uûivatelích, kte í se s Fakturoid aplikací b hem v˝voje v bec nesetkali. Sestavil jsem testovací scéná , kter˝ vedl participanty t mi nejhlavn jöími p ípady uûití: vytvá ení faktury, vytváení kontaktu a registrace. Tento testovací scéná , s mírnou obm nou, pouûil 44
5.3. Uûivatelské testování i v˝vojá Android verze. Protoûe podle Jakoba Nielsena není pot eba více jak 5 testovacích sezení [26], pozval jsem si na testování 3 participanty. Bylo hlavn nutné najít uûivatele z naöí cílové skupiny — ideáln to jsou ti, kte í pouûívají chytr˝ telefon iPhone a ve své ûivnostenské innosti vystavují zákazník m faktury. Tuto skute nost jsem si ov il p edtestov˝m dotazníkem. V p íloze E m ûete vid t cel˝ testovací scéná , kter˝ uûivatelé dostali. Následn uvádím v˝sledky z testovacích sezení s participanty.
Participant 1 Student vysoké ökoly technického zam ení, muû, rozmezí v ku 20–25. P edtestov˝ dotazník: 1. Máö zkuöenosti s pouûíváním p ístroje iPhone? Minimální, ale znám Android. 2. Máö zkuöenosti s vystavováním faktur? Nemám. Potestov˝ dotazník: 1. Bylo snadné se zaregistrovat? Ano, líbilo se mi, ûe sta ilo po zapsání I O kliknout na Hotovo na klávesnici a ne na OK tla ítko. Na druhou stranu m zmátlo, ûe po umíst ní kurzoru do linky nezmizí popisek vstupního pole. 2. Bylo snadné vytvo it fakturu? Nep iölo mi to sloûité, druhá faktura öla uû dob e. 3. Bylo snadné fakturu odeslat? Ano. (Ú astník ale dlouho hledal, jak poslat email a nechápal pro musí vypl ovat email v kontaktu — avöak takto jsou nastaveny procesy ve Fakturoid systému.) P i prvním sezení jsem zjistil v aplikaci spoustu programov˝ch chyb. Nap . uûivatel cht l potvrdit registraci, ale druhá valida ní hláöka se mu neobjevila. Ve formulá i kontaktu vstupní pole pro e-mail p evedlo první zadan˝ znak na velké písmeno. Dále nefungovalo smazání kontaktu. Z testování bylo také poznat, ûe ú astník netuöil, co znamená zkratka MJ (m rná jednotka) ve formulá i poloûky. Dále jsem zpozoroval delöí zamrznutí p ed objevením obrazovky pro poslání faktury e-mailem. Tyto chyby jsem následn hned opravil.
Participant 2 Grafik, muû, rozmezí v ku 20–25. P edtestov˝ dotazník: 1. Máö zkuöenosti s pouûíváním p ístroje iPhone? Mám iPhone 4S. 2. Máö zkuöenosti s vystavováním faktur? Ano, vystavuji, jsem OSV . 45
5. Testování Potestov˝ dotazník: 1. Bylo snadné se zaregistrovat? Ano. Ale ekal jsem, ûe po kliknutí na Hotovo na klávesnici si budu moci jeöt zkontrolovat zadané údaje. Ona se mi vöak registrace hned poslala. 2. Bylo snadné vytvo it fakturu? Ano. Ale není jasné, kde jsou vstupní pole. 3. Bylo snadné fakturu odeslat? Ano. Ale poté, co jsem ji ozna il jako zaplacenou, jsem se lekl, pro m la najednou z oranûové barvy barvu ernou. Je pravda, a to mi nedoölo, ûe uûivatel si m ûe chtít prohlédnout zadaná data. Hlavn v registraci ûádn˝ uûivatel nebude zvykl˝ na mou urychlující funkci odeslat formulá p i stisknutí Hotovo na klávesnici. Je z ejmé, ûe pro registraci se tato funkce nehodí. U ostatních formulá to ale zanechám. Jako grafik si ú astník hodn vöímal vzhledu a kritizoval nezv˝razn ní vstupních polí formulá e. Vypl ovat formulá e mu ale ve v˝sledku ned lalo ûádné problémy. erné ozna ení zaplacené faktury vychází z webového Fakturoid systému. Tuto poznámku jsem jiû Fakturoid t˝mu oznamoval, ale oni cht jí zachovat konzistenci mobilní aplikace s webovou verzí.
Participant 3 Podnikatel, muû, rozmezí v ku 26–30. P edtestov˝ dotazník: 1. Máö zkuöenosti s pouûíváním p ístroje iPhone? Uû jsem to drûel v ruce. 2. Máö zkuöenosti s vystavováním faktur? Ano. Potestov˝ dotazník:
1. Bylo snadné se zaregistrovat? Ano.
2. Bylo snadné vytvo it fakturu? Ano. 3. Bylo snadné fakturu odeslat? Ano. Zde uû aplikace fungovala v po ádku bez problém . Je zajímavé, ûe a koliv ú astník nezná iOS prost edí, rychle se zorientoval a v d l p esn , která tla ítka má pouûít.
P i uûivatelském testování se mi potvrdila nutnost jeho provád ní. Hlavn jeho provád ní na konci projektu, kdy aplikace má b˝t vystavena ve ejnosti. Programátor, a sám to cítím na sob , není schopen udrûet konzistenci vöech prvk a interakcí hlavn v poslední fázi v˝voje, kdy od zadavatele p ichází mnoho podn t ke zm nám a úpravám. Y 46
Kapitola
Vedení t˝mu Na projektu mobilních aplikací pro faktura ní systém Fakturoid jsme se podíleli dva v˝vojá i. Já vyvíjel nativní aplikaci pro iOS a Michal Ku era, student Fakulty informa ních technologií na VUT, m l na starost verzi pro Android. Tento v˝voj Android verze popsal ve své bakalá ské práci [27]. Kaûd˝ z nás dostal k dispozici z firmy Ackee na konzultace senior programátory — pro m to byl Senior iOS Developer, pro Michala Senior Android Developer. S nimi jsme m li moûnost se radit v otázkách, ve kter˝ch se jsme nemohli pohnout dop edu, a zárove oni nám poskytli rady, které frameworky pro v˝voj aplikací je vhodné pouûít. Hlavní komunikaci s Fakturoid t˝mem, jenû tvo ili t i v˝vojá i Fakturoid systému, ídil vedoucí projektu Ing. Martin P lpitel. Avöak i my dva programáto i mobilních aplikací jsme kv li rychlosti a p esnosti odpov dí komunikovali s Fakturoid t˝mem p ímo. Tuto strukturu komunikace jsem zanesl do diagramu na obrázku 6.1. Pro komunikaci na bázi v˝voje a pro pokládání rychl˝ch a krátk˝ch otázek jsme vyuûili aplikaci pro ízení projektu Basecamp.51 Basecamp umoû uje snadnou komunikaci ve vláknech, která oproti e-mailové p sobí více p ehledn ji. B hem v˝voje vzniklo na Basecampu 25 vláken o 281 p ísp vcích. V˝voj probíhal v krátk˝ch t˝denních iteracích, ve kter˝ch jsme kaûd˝ ned lní ve er rozeslali zainteresovan˝m osobám naöi stávající verzi aplikace se zm nami, které jsme ud lali — já p es TestFlight, Michal p es TestFairy (viz kapitola 4.5). Ve v˝vojovém t˝mu jsme museli také eöit obm nu pozice. P vodní Android programátor nebyl Michal Ku era, ale jin˝ student bakalá öké etapy. A koliv naöe jednotlivá práce nebyla navzájem závislá, zadal jsem mu, jako vedoucí, ûe si kaûd˝ t˝den budeme psát, co jsme za ten t˝den ud lali. On sám navrhl, ûe kaûdou ned li poöle report. Neposlal ani jeden. Následující t˝den jsem mu p es e-mail poslal, co jsem d lal já s otázkou, co d lal on. N kolikrát 51
basecamp.com
47
6
6. Vedení t˝mu
Fakturoid tým
Android Developer
Senior Android Developer
iOS Developer (já)
Project Manager
Senior iOS Developer
Obrázek 6.1: Schéma komunikace v t˝mu odpov d l, ûe zatím nepracoval, a pak p estal komunikovat. Spolupráci se studentem jsme ukon ili a vedoucí projektu Ing. Martin P lpitel p ivedl nového Android v˝vojá e — tím problémy v t˝mu byly vy eöeny.
Y
48
Záv r M˝m úkolem bylo zrealizovat nativní iPhone aplikaci pro faktura ní systém Fakturoid. Sou ástí v˝voje bylo vytvo ení papírové verze obrazovek aplikace, navrûení zm n do Fakturoid API v2, samotná implementace aplikace a nakonec otestování zrealizované aplikace v i akcepta ním a uûivatelsk˝m test m. Po celou dobu v˝voje jsem spolupracoval s bakalá sk˝m studentem, kter˝ vytvá el mobilní verzi Fakturoidu na systém Android. Vöechny tyto body se mi poda ilo splnit. Na za átku textu definuji poûadavky, které by v˝sledná aplikace m la mít. Tyto poûadavky jsem si rozd lil do skupin, které mi pomohly ur it, jaké funkce by m ly mít na obrazovkách spole né umíst ní. Z tohoto rozd lení jsem vycházel p i tvorb prvních návrh obrazovek. V reöeröi podobn˝ch aplikací se ukázalo, ûe konkuren ní eöení chybují hlavn v nezobrazování pro uûivatele pot ebn˝ch informací na viditelném míst , ale skr˝vají je, tím aplikace p sobí chaoticky. D leûit˝m poznatkem byla nutnost mít moderní sou asn˝ design. P i návrhu obrazovek jsem vycházel z webové verze systému Fakturoid. Vytvo il jsem transformaci grafiky, která z öirokého rozloûení vzhledu ud lala úzk˝ tok grafiky pasující do mal˝ch obrazovek mobil . Také jsem p em˝ölel, jak˝m zp sobem tvo it formulá e, které jsou stavebním prvkem aplikace, tak aby se uûivateli pohodln pouûívali. Na v˝sledné obrazovky jsem provedl Heuristickou evaluaci a poté jsme navrûen˝ design p inesli grafikovi, kter˝ nám vytvo il grafickou identitu ve stylu sou asného flat designu. V kapitole o návrzích jsem také sepsal funkce, které bylo nutné doplnit do druhé verze Fakturoid API, aby mobilní aplikace mohly poskytovat poûadovanou funk nost. Tento seznam poûadavk v˝vojá i Fakturoid systému následn sami implementovali. V kapitole o realizaci popisuji strukturu aplikace, jeû je standardn rozd lena na t i vrstvy — view, business, model —, kde vrstvy spolu komunikují pomocí návrhového vzoru Observer, jenû skv le dopl uje pouûit˝ framework RestKit, kter˝ mi usnadnil realizovat posílání HTTP poûadavk na API server a následn mapovat p ijatá JSON data do entitních objekt . Pro tvorbu formulá jsem cht l vyuûít knihovnu t etí strany, avöak musel jsem si formulá ové eöení napsat od za átku sám. Tato moje implementace vyrostla v eöení, které krom vlastního definování vzhledu ádk formulá e poskytuje také validaci vstup od uûivatele na základ regulárních v˝raz a umí 49
Záv r i kontrolovat íselné rozsahy. Navíc, uûivateli jsem zv˝öil pohodlí rychl˝m p eskokem kurzoru do dalöího vstupního pole pomocí klávesy Dále na klávesnici. Následn v kapitole rozebírám r zné eöené problémy a d vody pouûití dalöích framework . Aplikaci jsem b hem v˝voje testoval unit testy. Pro n které testy jsem vyuûíval lokální server, kter˝ simuloval funk nost ve ejného Fakturoid API serveru, hlavn pro p ípady otestování chybov˝ch událostí. P i záv ru v˝voje byla aplikace otestována proti akcepta ním test m a také jsem provedl uûivatelské testování. Poslední kapitolu jsem v noval popisu komunikace naöeho t˝mu v˝vojá mobilních Fakturoid aplikací s t˝mem v˝vojá Fakturoid systému. Hotové aplikace plánujeme p edstavit na p ehlídce tvorby mobilních aplikací AppParade.52 Návrh do dalöí verze Fakturoid aplikace je p idání Push notifikací o nezaplacen˝ch fakturách nebo podpora zm n uûivatelsk˝ch nastavení p ímo z aplikace. Do budoucna bych také cht l z v˝sledného kódu starajícího se o formulá e sestavit framework — formulá b˝vá hodn typick˝ poûadavek r zn˝ch aplikací. Také struktura celé aplikace je obecná, kdybych si z ní ud lal öablonu, uöet ilo by mi to hodiny startovního asu na v˝voji budoucích aplikací.
Y
52
AppParade je od prosince 2010 pravidelná tvrtletní p ehlídka domácí ( eské a slovenské) tvorby v oblasti aplikací pro p enosná komunika ní za ízení – mobilní telefony a tablety. Více na m.appparade.cz/about.
50
Literatura [1] MAHAPATRA, Lisa. Android Vs. iOS: What’s The Most Popular Mobile Operating System In Your Country? International Business News [online]. 2013 [cit. 2014-05-05]. Dostupné z: http://www.ibtimes.com/android-vs-ios-whats-most-popularmobile-operating-system-your-country-1464892 [2] FENDRYCH, Adam. User Experience – poznejte své uûivatele. Lupa.cz: Server o eském internetu [online]. 2010 [cit. 2014-04-26]. Dostupné z: http://www.lupa.cz/clanky/user-experience-poznejtesve-uzivatele/ [3] NIELSEN, JAKOB. 10 Usability Heuristics for User Interface Design. In: Nielsen Norman Group [online]. 1995 [cit. 2014-04-02]. Dostupné z: http://www.nngroup.com/articles/ten-usability-heuristics/ [4] LICHNOVSKÁ, Pavla a Eva KARBEROVÁ. Heuristická anal˝za. In: Testování a hodnocení rozhraní [online]. 2009 [cit. 2014-04-02]. Dostupné z: http://human-computer-interaction.webnode.cz/testovani-ahodnoceni-rozhrani/metody-testovani/heuristicka-analyza/ [5] About Objective-C. APPLE INC. Programming with Objective C [online]. 2012 [cit. 2014-04-10]. Dostupné z: https: //developer.apple.com/library/mac/documentation/cocoa/ conceptual/ProgrammingWithObjectiveC/Introduction/ Introduction.html [6] THE RESTKIT PROJECT. RestKit [online]. 2012 [cit. 2014-04-10]. Dostupné z: http://restkit.org/ [7] LARMAN, Craig. Applying UML and patterns: introduction to objectoriented analysis and design and iteractive development. 3rd ed. New Jersey: Prentice-Hall, 2005, 703 s. ISBN 01-314-8906-2. [8] Design patterns: elements of reusable object-oriented software. Massachusetts: Addison-Wesley, c1995, xv, 395 s. ISBN 02-016-3361-2. 51
Literatura [9] User Interface. Webopedia [online]. 2014 [cit. 2014-04-14]. Dostupné z: http://www.webopedia.com/TERM/U/user_interface.html [10] JONÁä, Martin. Návrhové principy: DRY. Zdroják.cz: O tvorb webov˝ch stránek a aplikací [online]. 2012 [cit. 2014-04-14]. Dostupné z: http:// www.zdrojak.cz/clanky/navrhove-principy-dry/ [11] Mogenerator [online]. 2009 [cit. 2014-04-16]. Dostupné z: http:// rentzsch.github.io/mogenerator/ [12] Mogenerator + Xmo’d [online]. 2009 [cit. 2014-04-16]. Dostupné z: https: //github.com/rentzsch/mogenerator [13]
URECH, Juraj. Jak upéct lepöí formulá v iOS. In: mDevCamp: konference pro mobilní v˝vojá e 25. kv tna, 2013 Praha [PDF soubor]. 2013 [cit. 2014-04-18]. Dostupné z: https://www.dropbox.com/ sh/wxea4ilasosdwrz/O-b5dp2dvL/107%20%28Jan%C3%A1k%29/02%20%20Jak%20up%C3%A9ct%20lep%C5%A1%C3%AD%20formul%C3%A1%C5%99% 20v%20iOS%20%28Juraj%20%C4%8Eurech%2C%20Inmite%29.pdf
[14] Nib Files. APPLE INC. Resource Programming Guide [online]. 2012 [cit. 2014-04-18]. Dostupné z: https://developer.apple.com/library/ios/ documentation/cocoa/conceptual/loadingresources/cocoanibs/ cocoanibs.html [15] Search: swipe table cell. GitHub [online]. 2014 [cit. 2014-04-23]. Dostupné z: https://github.com/search?q=swipe+table+cell&ref= searchresults&type=Repositories [16] Apple Events: WWDC. June 10, 2013. Apple [online]. 2013 [cit. 2014-0423]. Dostupné z: http://www.apple.com/apple-events/june-2013/ [17] WWDC in detail. Apple: WWDC [online]. 2014 [cit. 2014-05-06]. Dostupné z: https://developer.apple.com/wwdc/more/ [18] View Controller Basics: About Navigation Controllers. APPLE INC. View Controller Programming Guide for iOS [online]. 2012 [cit. 2014-04-24]. Dostupné z: https://developer.apple.com/ library/ios/featuredarticles/ViewControllerPGforiPhoneOS/ AboutViewControllers/AboutViewControllers.html [19] Using Unwind Segues. APPLE INC. IOS Developer Library [online]. 2013 [cit. 2014-04-24]. Dostupné z: https://developer.apple.com/library/ ios/technotes/tn2298/_index.html [20] SCHORE, Mike. CocoaSPDY: SPDY for iOS / OS X. Twitter: Engineering Blog [online]. 2013 [cit. 2014-05-03]. Dostupné z: https:// blog.twitter.com/2013/cocoaspdy-spdy-for-ios-os-x 52
Literatura [21] OLIVEIRA, Victor. Flurry error reporting vs other error reporting services such as Crittercism & Crashlytics etc. In: Stackoverflow [online]. 2013 [cit. 2014-04-25]. Dostupné z: http://stackoverflow.com/a/19527698/ 1054550 [22] Android End of Life. In: TestFlight [online]. 2014 [cit. 2014-0425]. Dostupné z: http://help.testflightapp.com/customer/portal/ articles/1450414 [23] PEREZ, Sarah, Ryan LAWLER a Darrell ETHERINGTON. TestFlight Owner Burstly Acquired By Apple. In: TechCrunch [online]. 2014 [cit. 2014-04-25]. Dostupné z: http://techcrunch.com/2014/02/21/rumortestflight-owner-burstly-is-being-acquired-by-apple/ [24] Domain Specific Language. Cunningham & Cunningham, Inc. [online]. 2013 [cit. 2014-04-30]. Dostupné z: http://c2.com/cgi/ wiki?DomainSpecificLanguage [25] RubyGems Guides. RubyGems.org: your community gem host [online]. 2009 [cit. 2014-04-30]. Dostupné z: http://guides.rubygems.org/ [26] NIELSEN, Jakob. Why You Only Need to Test with 5 Users. Nielsen Norman Group [online]. 2000 [cit. 2014-05-01]. Dostupné z: http://www.nngroup.com/articles/why-you-only-need-to-testwith-5-users/ [27] Ku era, Michal. Mobilní aplikace Fakturoid pro systém Android. Bakalá ská práce. Praha: eské vysoké u ení technické v Praze, Fakulta informa ních technologií, 2014.
53
P íloha
Seznam pouûit˝ch zkratek API Application Programming Interface ARES Administrativní registr ekonomick˝ch subjekt DI
Da ové identifika ní íslo
DPH Da z p idané hodnoty DRY Don’t Repeat Yourself DSL Domain Specific Language HTML HyperText Markup Language I O Identifika ní íslo organizace IDE Integrated Development Environment JSON JavaScript Object Notation REST Representational State Transfer UI User Interface URL Uniform Resource Locator
55
A
P íloha
Dokumenty
57
B
B. Dokumenty
Obrázek B.1: Schéma transformace obsahu
58
P íloha
Wireframes
59
C
Fakturoid | Log in
1
Fakturoid | Sign up
2
Fakturoid | Terms and Conditions
3
Fakturoid | Dashboard
4
Fakturoid | Reload obrazovek
5
Fakturoid | Faktury
6
Fakturoid | Faktura -- vyber data zaplaceni
7
Fakturoid | Faktura -- view
8
Fakturoid | Faktura -- stavy
9
Fakturoid | Faktura -- nahled
10
Fakturoid | Faktura -- view -- slozitejsi verze
11
Fakturoid | Faktura -- creating/editing
12
Fakturoid | Faktura -- new item
13
Fakturoid | Faktura -- splatnost
14
Fakturoid | Kontakty
15
Fakturoid | Kontakt -- view
16
Fakturoid | Kontakt -- faktury
17
Fakturoid | Kontakt -- creating/editing
18
Fakturoid | Ja
19
Fakturoid | Použite ikony ve webove verzi
20
P íloha
Ukázky aplikace
81
D
D. Ukázky aplikace
Obrázek D.1: Formulá faktury, odb ratel není z proto zobrazila informa ní hláöka.
82
eské republiky, uûivateli se
P íloha
Materiály k uûivatelskému testování
83
E
1
Pˇ redtestov´ y dotazn´ık
Participant: 1. M´aˇs zkuˇsenosti s pouˇz´ıv´an´ım pˇr´ıstroje iPhone? Jak dlouho? 2. M´aˇs zkuˇsenosti s vystavov´an´ım faktur? Jak ˇcasto fakturujeˇs?
2
Testovac´ı sc´ en´ aˇ r D˚ ukladnˇe si pˇreˇcti tento sc´en´aˇr pˇred zaˇca´tkem testu. Bˇehem cel´eho testu pouˇz´ıvej metodu tzv. myˇslen´ı nahlas“. ” Pokud Ti nen´ı nˇeco jasn´e, neboj se zeptat. Sezen´ı m˚ uˇzeˇs kdykoliv ukonˇcit. Udˇelej n´ asleduj´ıc´ı akce:
ˇ je 1. Otevˇri aplikaci Fakturoid a zaregistruj se. M˚ uˇzeˇs vyuˇz´ıt smyˇslen´a data. Tv´e ICO 47123737 (jsi Microsoft). ˇ 24240826). Vyfakturuj jim prodej 22 kancel´aˇrsk´ 2. Vystav fakturu firmˇe Ackee (ICO ych ˇzidl´ı o hodnotˇe jedn´e 5499 Kˇc. Ostatn´ı hodnoty faktury m˚ uˇzeˇs nechat tak, jak jsou. 3. Zjistil jsi, ˇze cena za ˇzidli je pouze 5399 Kˇc. Vytvoˇrenou fakturu oprav. 4. Fakturu jim poˇsli na email [email protected] 5. D´ale vystav fakturu firmˇe CompanyAbc, kter´a je ze zemˇe Francie. Vyfakturuj jim prodej 15 kancel´aˇrsk´ ych ˇzidl´ı o hodnotˇe jedn´e 2000 Kˇc. Platba hotovˇe, splatnost faktury mˇej jeden mˇes´ıc, jazyk faktury angliˇctina. Fakturu pot´e oznaˇc pouze za zaplacenou. 6. Z aplikace se odhlaˇs.
3
Potestov´ y dotazn´ık
1. Bylo snadn´e se zaregistrovat? 2. Bylo snadn´e vytvoˇrit fakturu? 3. Bylo snadn´e fakturu odeslat?
P íloha
Obsah p iloûeného CD
85
F
F. Obsah p iloûeného CD
Text DP_Ostatnicky_Jiri_2014.pdf...........text práce v PDF formátu src.........................zdrojové soubory textu v LATEX formátu Wireframes Fakturoid-wireframes-v3......... wireframes v klikatelném HTML zobrazení Fakturoid-wireframes-v3.pdf .......... wireframes v PDF formátu
86
