Masarykova univerzita Fakulta informatiky Implementácia sady aplikácií na organizáciu práce a casu pomocou metodiky GTD. Bakalárska práca Martin Krivuš Brno, Jeseň 2010 Prehlásenie Prehlasujem, že táto bakalárska práca je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich Čerpal, v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj. Vedúci práce: Mgr. Jiří Materna ii Poďakovanie Ďakujem všetkým, ktorí sa podieľali na testovaní mojich prototypov, a poskytli mi cenné informácie o použiteľnosti uživatel'ských rozhraní. Obzvlášť ďakujem Mgr. Jirkovi Maternovi za ochotu viest' moju prácu. Marekovi Novému za konzultácie grafickejstránky projektu. iii Zhrnutie Cieľom práce je navrhnut' a implementovat' sadu aplikácií na organizáciu úloh a casu pomocou metodiky GTD. Systém by mal byt' zložený z centrálneho webového úložiska a uži-vatel'skejaplikácie schopnejpracovat' bez pripojenia. Dôraz je kladený na prístupnosť a jednoduchost', ale zároven variabilitu použitia pre širokú škálu užívateľských potrieb. Hlavným prínosom práce je schopnost' systému rozhodovat' sa za užívateľa, ktoré zadané úlohy je možné plnit' a nezat'ažovat' ho ostatnými. iv Kľúčové slová GTD, D'ango, iPhone, iOS, XCode, Python, Objective-C v Obsah 1 Úvod............................................. 1 1.1 Motivácia a ciel' práce................................ 1 1.2 Prehl'ad práce..................................... 1 2 Metodika GTD....................................... 3 2.1 Organizacný proces.................................. 3 2.1.1 Zbieranie záležitostí............................. 4 2.1.2 Spracovanie.................................. 5 2.1.3 Organizácia.................................. 6 2.1.3.1 Projekty............................... 6 2.1.3.2 Kontexty.............................. 6 2.1.3.3 Kalendár a zoznam ďalších úloh ................ 7 2.1.3.4 Nevykonateľné položky..................... 7 2.1.4 Revízia..................................... 7 2.1.5 Vykonávanie úloh .............................. 8 3 Návrh systému....................................... 9 3.1 Existujúce riešenia .................................. 9 3.2 Architektúra...................................... 11 4 Dátové úložisko....................................... 13 4.1 Dátový model..................................... 13 4.2 Python a Django.................................... 14 4.2.1 Štruktúra projektu.............................. 15 4.2.2 Objektovo-relaCné mapovanie ....................... 15 4.2.3 Administračné rozhranie .......................... 16 4.2.4 Neschémová databáza ............................ 17 4.2.5 Mapovanie URL na pohľady........................ 17 4.2.6 Šablonovací jazyk ............................... 18 4.3 Aplikačné rozhranie................................. 19 5 Webová aplikácia ...................................... 21 5.1 Uživatel'ské rozhranie a vizuálny koncept..................... 21 5.2 Javaskript a knižnica jQuery............................. 22 5.3 CSS3 .......................................... 22 6 Aplikácia pre iPhone a iPad ................................ 24 6.1 iPhone, iPad a operacný systém iOS........................ 24 6.2 Objective-C a Cocoa.................................. 25 6.3 Vývojové prostredie Xcode ............................. 26 6.4 Profily na testovanie................................. 27 6.5 Dátové modelovanie a technológia Core Data................... 27 6.6 Uživatel'ské rozhranie ................................ 27 6.7 Geolokacné dáta.................................... 29 7 Záver ............................................. 31 vi Bibliografia............................................ 32 A Obrazové prílohy...................................... 33 B Obsah CD.......................................... 39 vii Kapitola 1 Úvod 1.1 Motivácia a ciel' práce Na konci 20. storočia pozorujeme prechod od priemyselnejspolocnosti k informačnej. Nové technológie ako internet, e-mail alebo mobilný telefón, nám umožnujú pracovat' kdekoľvek sa nachádzame. Naša práca teda už nie je iba jedno miesto, kde vykonávame tú istú cin-nost' každý den. Nemá už jasné hranice kedy, kde, a co. Narastá množstvo informácií, ktoré musíme každý den spracovať, a navyše s nimi väcšinou nedokážeme urobit' nic vtedy, ked' sa k nám dostanú, alebo ked' si na ne spomenieme. výsledkom je stres, pretože musíme množstvo rozlicných povinností nielen plnit', ale zároven mysliet' na tie, ktoré nás ešte iba cakajú. Väcšina z nás intuitívne používa nejaký kalendár, alebo diár na poznámky, ktoré nie sú spojené s nejakým casom. Spôsob, ako s týmito pomôckami pracujeme, je ale väcšinou neefektívny. Vel'a casu nám zaberie rozhodovanie, kam ktorá informácia patrí, kedy a ako sa k nejznovu dostaneme. Niekedy zase nemáme pri sebe nic, kde by sme si poznamenali co nás práve napadlo, prípadne co od nás niekto chcel. Držíme teda ajtak viac alebo menej vecí v hlave, no náš mozog na nieco také nie je stavaný. "Naša mysel' nemá svoju vlastnú mysel'"[14]. Nedokáže plánovat', kedy je nutné, alebo vhodné spomenúť si na nieco. ako reakciu na všetky tieto problémy sformuloval David allen metodiku na organizáciu casu GTD (Getting Things Done) a v roku 2001 ju popísal v rovnako nazvanejknihe. David Allen sa venuje optimalizácii pracovných procesov a so svojimi dlhorocnými skúsenosťami vytvoril jednoduchý proces pozostávajúci z piatich bodov, umožnujúci organizovat' prácu efektívne a bez stresu. Vo svojejknihe ale opisuje iba koncept, nevnucuje svojim citatel'om nejaký konkrétny spôsob alebo nástroj na jeho realizáciu. práve o vytvorení takéhoto nástroja je moja práca. Výsledok je teda fungujúca sada aplikácií, zjednodušujúcich organizáciu casu a postup ich vytvorenia z technického hl'adiska. 1.2 Prehl'ad práce Text je rozdelený do šiestich kapitol. Prvá kapitola uvádza do problematiky organizácie casu a vysvetl'uje nutnost' zaoberat' sa jej optimalizáciou v dnešnej dobe. obsahuje štruktúru práce, kde sú v krátkosti zhrnuté jednotlivé kapitoly. Druhá kapitola pojednáva o metodike GTD a jej princípoch. kniha Getting Things Done [14] je dost' obsiahla a po jejprecítaní môže byt' clovek trochu zmätený. Nie je to totiž 1 1.2. PREHL'AĎ PRÁCE nejaký jednoduchý návod, ale skôr núti citatel'a premýšľať o svojich pracovných návykoch a ako ich zlepšit'. Táto kapitola teda môže slúžit' ako interpretácia najdôležitejších poznatkov z tejto knihy, ktoré budem využívat'. V poslednejpodkapitole je prehl'ad najznámejších softvérových riešení a obhájená potreba vytvorit' úplne nový systém. Tretia kapitola sa nezaoberá priamo implementáciou z technického hl'adiska. Obsahuje návrh celého systému a jednotlivých aplikácií, ktoré ho tvoria z pohl'adu používateľa. Sada aplikácií obsahuje webové rozhranie a aplikáciu pre iPhone, ktoré sa navzájom synchronizujú pomocou jedného centrálneho úložiska dát. Vysvetľujem preco som sa rozhodol pre takýto koncept, a preco som si ako mobilné zariadenie vybral práve iPhone. Obsahom štvrtej kapitoly je implementácia dátového úložiska, s ktorým sa synchronizuje iPhone a webové rozhranie. Popisujem tu celý dátový model tohoto systému a jeho vol'ne prístupné aplikacné rozhranie, umožnujúce vytvoriť aplikácie ajpre iné mobilné zariadenia a operacné systémy. Je tu popísaný proces synchronizácie dát s dôrazom na efektivitu pri mobilnom zariadení. Citatel' sa tu dozvie preco som sa rozhodol pre programovací jazyk Python spolu s knižnicou Ďjango1, a dôvody využitia schémovej a neschémovej databázy naraz. Piata kapitola predstavuje technické riešenie webového rozhrania. Je generované prevažne pomocou jazyka Javascript s knižnicou jQuery2. Práca s ním je tak vel'mi príjemná a interaktívna. Vizuálne a funcionalitou pripomína viacejbežné programy vnútri operacného systému, ako internetovú stránku. Problémy takéhoto návrhu sú vysvetlené práve v tejto casti práce. V šiestej, najrozsiahlejšej kapitole je popísaný vývoj aplikácie pre iPhone. Je tu rozoberané použitie programovacieho jazyka Objective-C v operacných systémoch Mac OS a iOS. Jeho špecifické vlastnosti pomáhajú vytvárať prehľadný a dobre štrukturovaný kód, ktorý je zároven efektívny, ked'že tento jazyk je nadmnožina jazykov C a C++. Opisujem d'alejprá-cu s vývojovým prostredím Xcode od firmy Apple, vd'aka ktorému denne pribúdajú stovky nových aplikácií pre ich zariadenia. To zahrna programy ako Interface Builder pre pohodlné vytváranie grafických rozhraní, alebo iPhone Simulator umožnujúci testovat' chod programu vo virtuálnom iPhone. V závere je zhrnutý prínos celejpráce a nacrtnutý možný d'alší vývojtohoto systému. Všetky jeho súcasti sú navrhnuté tak, že umožnujú jednoduchú správu, prípadne doplna-nie d'alších funkcií. Nie všetky nápady sa podarilo zahrnút' do výsledného riešenia, takže projekt má ešte potenciál na d'alší vývoj. 1. Knižnica pre jazyk Python, určená na rýchly vývoj menších webových aplikácií. 2. Knižnica pre jazyk javascript, stierajúca rozdiely medzi prehliadacmi, urcená na pohodlnejšie písanie viacej abstraktného kódu. 2 Kapitola 2 Metodika GTD Za 50 rokov minulého storočia sa naša spoločnosť pretransformovala od priemyselnejk znalostnej. „Hlavný dôvod zvyšovania úrovne stresu je, že povaha našejpráce sa zmenila rapídnejšie, než výuka toho, ako sa s prácou vysporiadat'."[14] U väčšiny profesií došlo k výraznému posunu od výrobnejlinky, kde každý človek vykonával jednu konkrétnu činnost', k práči s informáčiami, komunikáčií, a spolupráči s inými profesiami. Hraniče definujúče naše pračovné povinnosti už nie sú také jasné, a podstata našeho zamestnania sa mení každý týžden, den, alebo z hodiny na hodinu. Preto aby sme mali obrovské množstvo práče a povinností stále pod kontrolou, musíme venovat' nejaký čas ičh organizáčií. Autorom metodiky Getting Things Done, známejpod skratkou GTD, je David Allen. Prvý krát sa tento pojem objavil v roku 2001 v knihe Getting Things Done: How to ačhie-ve stress-free produčtivity[14]Ide o vel'mi jednodučhú, avšak efektívnu metódu, ako dostat' pod kontrolu nepreberné množstvo informáčií a úloh, s ktorými sa denne stretávame. Po po-čhopení pár prinčípov je človek sčhopný systematičky sa vysporiadať so stresom pramenia-čim z organizáčie práče, a plne končentrovat' svoje myšlienky na úlohu, ktorú momentálne plní. Systém zbavuje človeka nutnosti rozhodovat' sa, kam ktorú informáčiu zaradiť, práve ked' je potrebné sústrediť sa na niečo iné, no zároven by nič nemalo uniknúť neskoršejpo-zornosti. „Kniha obsahuje stratégiu, ako mat' viačejenergie, byt' viač uvolnený, a dokončit' viačejvečí s ovel'a menšou námahou."[14] 2.1 Organizačný proces Mozog človeka nie je prispôsobený na to, aby si pamätal a organizoval všetky svoje povinnosti. Podl'a Davida Allena je teda nutné používat' nejaký externý systém mimo našu hlavu, do ktorého sa dajú rýčhlo ukladať všetky myšlienky. Nie je potom zaťažovaný týmito informáčiami, a môže sa v plnejmiere sústrediť na to, čo momentálne vykonáva. Metodika GTD, organizuje tieto myšlienky od ičh vypustenia z hlavy až po pretvorenie na vykonatel -né úlohy pomočou piatičh základnýčh bodov. Prvým z ničh je zozbieranie všetkýčh „záležitostí", ktoré zbytočne zat'ažujú náš mozog, alebo nemáme potrebu sa im aktuálne venovat'. Druhým krokom je ičh spracovanie, kde sa zo záležitostí stávajú konkrétne úlohy. Dalejičh organizácia do logičky podobnýčh čelkov, revízia, a posledným piatym ktorokom je vykonávanie úloh. 3 2.1. ORGANIZAČNÝ PROCES "záležitosti" 1 Schránka I Čo je to? I nie Projekty (plánovanie) -<____ Aká je ďalšia úloha? Kôš Niekedy/možno Založiť pre neskoršie dohľadanie Plány projektov (prehodnotiť úlohy) Zaberie to menejnež 2 minúty? nie Čakanie (na dokončenie od niekoho iného ) Kalendár (úlohy na vykonanie v špecifický čas) Ďalšie akcie (Na vykonanie čo najskôr) Zdroj: David A.: Getting Things Done Obrázok 2.1: Graf organizácie úloh. Graf zobrazuje podrobnejšie jednotlivé kroky spracovania záležitostí až na konkrétne, vykonateľné a vykonané úlohy. Tenko oznaCené položky patria k fázi zbierania a spracovania, hrubo vyznaCené k fázi organizácie. 2.1.1 Zbieranie záležitostí Všetko, co zatiaľ nemá definovaný požadovaný výsledok budeme nazývat' záležitosti. Celý proces GTD zacína zbieraním záležitostí do takzvanejschránky. Je to nejaké virtuálne miesto, kam putuje všetko z nášho života, co by nás mohlo alebo malo niekedy zaujímat'[14]. Môžeme si ju predstaviť ako fyzickú priehradku, do ktorejukladáme papiere, nápady, úcty, požiadavky od d'alších ludí, prípadne poštu, aby sme ich mohli neskôr spracovať. Je vel'mi dôležité, aby sa to dalo spravit' co najrýchlejšie, bez toho aby nás to obťažovalo, pretože práve rýchlosť, s akou dokážeme vypustit' prec svoje myšlienky a starosti z hlavy je kl'úcová v celej metodike. Zbieranie záležitostí je prvý krok k tomu, aby boli veci hotové. Zatiaľ ešte nevieme, ci sa jedná o vykonatel'né úlohy, alebo aké požiadavky treba splnit' na ich vykonanie. Rýchlost'ou 4 2.1. ORGANIZAČNÝ PROCES a efektivitou zbierania záležitostí sa líšia jednotlivé pomôcky a nástroje na organizáciu casu, a práve jednoduché používanie schránky je vel'a krát rozhodujúce pri ich výbere. 2.1.2 Spracovanie V pravidelnom case je potrebné schránku vypráznit', a zozbierané informácie spracovať. Je dobré túto cinnost' vykonávat' v konkrétnu dobu pocas dna a zvyknúť si na to, alebo jednoducho vtedy, ked máme nejakú volnú chvíl'u. Táto cast' procesu vyzerá podobne fázi zbierania informácií, ale je dôležité ich oddelit'. Nemôžeme jednotlivé informácie triedit' pri ich zbieraní, pretože vtedy pravdepodobne vykonávame inú úlohu, a dlhším spracovávaním by sme sa dostali z jejkontextu. Navyše ked' spracovávame jednotlivé položky dávkovo, robíme to efektívnejšie. Pri spracovaní si pokladáme vel'mi dôležitú otázku. Je to vykonatel'né, alebo je potrebné kôli tomu vykonat' nejakú úlohu?[14]Podl'a priloženého grafu na obr. 2.1. máme na výber z troch možností kam akciu zaradit', pokial' nie je vykonatel'ná. • Odstrán. Položka pravdepdobne nebude nikdy potrebná, preto sa jejmôžeme zbavit'. • Niekedy/možno. Nieco bude musiet' byt' dokoncené neskôr v budúcnosti, ale momentálne nevieme kedy. • Ulož. Položka je nejaká informácia, ktorá môže byt' užitocná neskôr. Vykonatel'né položky reprezentujú skupinu záležitostí, pre ktoré musí byt' vykonaná nejaká úloha. [14] Treba si pri každejz nich položit' 2 otázky. Patrí táto úloha k nejakému projektu? A aká je "d'alšia úloha"? Ak dokážeme zadefinovať nejaký ciel', ktorý dosiahneme vykonaním viacerých úloh patriacich do logického celku, môžeme položku zaradit' do skupiny projektov. Ak pre záležitost' vieme zadefinovať nejakú jednu konkrétnu fyzickú úlohu, ktorú je potrebné vykonat', máme na výber z troch možností: • Vykonaj úlohu. Pokiaľ vykonanie úlohy zaberie menejako 2 minúty, mali by sme ju teraz vykonat'. David Allen to nazýva pravidlo dvoch minút. Neskoršia organizácia takejto nenárocnejúlohy by totiž vo výsledku zabrala viacejcasu. • Deleguj. Ak vykonanie úlohy trvá dlhšie ako 2 minúty, je potrebné dat' si otázku, som správny clovek na dokoncenie tejto úlohy? Ak je odpoved' nie, treba ju delegovat' príslušnému cloveku.[14] • Naplánuj Ostatné dve možnosti nevyhovujú, teda som správny clovek na dokoncenie úlohy, a zároven jejvykonanie zaberie viacejako 2 minúty. Je nutné túto položku pridat' do jedného alebo viacerých zoznamov "d'alších úloh", aby sa spracovala zorganizovala neskôr.[14] 5 2.1. ORGANIZAČNÝ PROCES 2.1.3 Organizácia V grafe na obrázku 2.1. sú hrubým orámovaním vyznacené casti, ktoré reprezentujú vzniknuté kategórie informácií a úloh z fáze spracovania. V tejto casi metodiky ich musíme zorganizovat' tak, aby sme pre každú z nich vedeli, kedy je nutné ju vykonat', k akému projektu patrí a ci vôbec, a v akom kontexte sa dá úloha vykonat'. Jednoducho akciu zaradit' na potrebné miesto, aby sa dala l'ahko dohl'adat' podl'a aktuálnych potrieb. Alebo aby na seba upozornila v správny cas (napríklad zápisom v kalendári). 2.1.3.1 Projekty Niektoré úlohy ma ú spolocřné ciele, ale sú to rozdielne kroky k eho dosiahnutiu. Preto ich pri spracovaní zoskupujeme do logických celkov ktoré nazývame projekty. "Projekt je nejaký jasne definovaný ciel', ktorý potrebuje na splnenie viac ako jeden krok Dôvod za takouto definíciou je ten, že ak jeden krok nedokoncí nejaký ciel', je nutné niekde zapísat' že to dokoncia nejaké d'alšie. [14] Inak by sme si to museli pamätat', a tým by sa strácala podstata metodiky. Dôležitou cast'ou organizácie je plánovanie projektov. Tu máme priestor na to vytvo-rit' si usporiadaný zoznam úloh, ktoré treba vykonat' na dosiahnutie ciel'a projektu. Môžu nám pri tom vzniknút' d'alšie úlohy, preto vidíme na grafe organizácie prechod od plánov projektov k otázke aká je d'alšia úloha. 2.1.3.2 Kontexty Nie vždy môžeme pracovat' na každejz úloh, preto sú v metodike definované takzvané kontexty. Vo svojej podstate je to pomenovaná prerekvizita, ktorá musí byt' splnená na to aby sme mohli konkrétnu úlohu vykonat'. Najcřastejšie je to nejaká lokalita v ktorej sa nachádzame, ale môže to byt' aj nejaký nástroj s ktorým pracujeme, prípadne osoba, s ktorou musíme hovorit'. Napríklad pre úlohu "kúpit' žiarovku"by bol kontext nazvaný obchod, a možno nie akýkol'vek obchod, ale práve taký v ktorom sa dá kúpit' žiarovka. Sú l'udia ktorí takéto radenie nepotrebujú, pretože metodiku využívajú napríklad iba v zamestnaní, kde majú všetky pracovné prostriedky ako pocřítat', alebo telefón na dosah. Pre tých, ktorí organizujú pomocou GTD celý svoj život, alebo cřasto menia vo svojom zamestnaní prostredie, je práve práca s kontextami kl'úcová a dôležitejšia ako organizácia pod-l'a projektov. Je vhodné vytvárat' si na ne samostatné zoznamy úloh, a na tie si potom vytvá-rat' pripomienky do kalendára alebo iného systému, vtedy ked' bude splnená prerekvizita kontextu. Podl'a metodiky patrí každá úloha práve do jedného z nich, ak sa nám teda stane, že nejakú úlohu potrebujeme dat' do viacerých zoznamov, pravdepodobne ich nemáme správne navrhnuté. "Ked'že kontext je prvé kritérium výberu úloh, na ktorých sa chystáme pracovat', zoznamy úloh zoradené podl'a nich šetria stratený cas pri rozhodovaní."[14] 6 2.1. ORGANIZAČNÝ PROCES 2.1.3.3 Kalendár a zoznam d'alších úloh Kalendár je jedna dvoch možností, kam sa dostanú úlohy zo skupiny na plánovanie. Tu je striktne dané, že to musia byt' jedine úlohy: spojené s nejakým konkrétnym casom, alebo spojené s nejakým konkrétnym dnřom. Nemôžeme napríklad zapisovat' do kalendára na d'alší denř úlohy, ktoré chceme mat' cřo najskôr splnené. Mohlo by sa stat', že v ten denř na nich ani nezažneme pracovat', a už nebudeme mat' v žiadnom inom zozname zmienku o nich. Mohli by sme sa tiež dostat' do nekonecřnej slucřky presúvania úloh vždy na d'alší denř. Z tohoto dôvodu všetko ostatné, cřo nemá žiadnu spojitost' s cřasom alebo dátumom, patrí do zoznamu d'alších úloh.[14] Ten je potom potrebné casto revidovat' vo vol'nom case. 2.1.3.4 Nevykonatel'né položky Nevykonateľné položky patria do troch kategórií. Sú nimi kôš, niekedy/možno a založenie pre neskoršie dohl'adanie. Kôš je v priehradka slúžiaca na úplné vymazanie položky z nášho systému, a založenie položky pre neskoršie dohl'adanie si môže každý predstavit' inak podl'a toho, s cřím pracuje. Predpokladáme teda len, že je to pre nás stále nejaká zaujímavá informácia, ktorú budeme vediet' po tomto spracovaní dohl'adat'. Najdôležitejší z týchto zoznamov je niekedy/možno. Je to schránka na úlohy, ktoré by sme z nejakého dôvodu chceli dokoncit', ale momentálne nemôžme. Nie sú vykonateľné iba teraz, nie úplne! Chceme ich niekde docasne založit', aby sme na ne nezabudli. [14] 2.1.4 Revízia Revízia je cřast' procesu, pri ktorej sa pozeráme na naše úlohy v príslušných intervaloch a na príslušnej úrovni.[14] Pravidelná revízia nás uist'uje, že v našom systéme je všetko, cřo má byt' a udržuje v nás pocit kontroly. David Allen odporúcřa vykonávat' revíziu v dvoch intervaloch: denne a týždenne. Kalendár obsahuje položky, ktoré sa z nášho systému vytratia, ak ich v ten denř nespravíme. Pretože na ne neexistuje odkaz nikde inde ako v kalendári, práve ten by mal byt' prvá vec ktorú revidujeme každý denř. Popri kalendári treba kontrolovat' cřasto aj náš zoznam d'alších úloh, lebo sú v nřom položky, ktoré majú byt' dokoncřené tak skoro, ako je to možné. Mali by sme im menit' prioritu, porovnávat' ich prioritu s tými, ktoré máme v kalendári a na základe toho sa rozhodovat', kedy budeme ktoré úlohy vykonávat'. V týždennej revízií by sme sa mali pozerat' na náš systém úloh ako na celok. Je to vhodná doba na to aby sme sa zbavili nepotrebného, zrevidovali všetky projekty a zoznamy.[14] Zárovenř pri nej môžeme odstránit' nepotrebné, alebo neaktuálne položky, prípadne pridat' nejaké d'alšie, ktoré si uvedomíme až pri širšom pohl'ade na niektorý z našich zoznamov. Nechceme ich ale nechat' prejst' celým procesom od pridania do schránky, ked'že práve teraz by sme pri pohl'ade na celý systém mali vediet' presne, kam patria. Neskôr by sme to zbytocřne zist'ovali znovu. 7 2.1. ORGANIZAČNÝ PROCES 2.1.5 Vykonávanie úloh Posledným krokom v celom procese organizovania je vykonávanie úloh. Po získavaní, spracovaní, organizovaní a revidovaní úloh, by sme mali mat' všetky z nich pripravené v jednotlivých zoznamoch tak, aby sme s co najmenšou námahou mohli vybrat' spomedzi tých, ktoré môžme, alebo potrebujeme plnit'. (Často l'udia obvinujú svojnástrojna organizáciu úloh z toho, že majú málo casu a nic nestíhajú. Naopak úlohy nie je najdôležitejšie organizovat', ale práve plnit'. Na to aby sme si vybrali správne, ktoré úlohy je najvhodnejšie plnit', slúžia štyry kritéria v tomto poradí: 1. Kontext. Niektoré úlohy nemôžeme vykonat' kdekol'vek, ale potrebujeme na to nejaké konkrétne miesto, alebo pomôcku. Preto to, co nás najviac limituje vo výbere úloh je kontext, v ktorom sa dajú vykonat'. 2. Dostupný čas. Pokiaľ nemáme dostatok casu na dokoncenie úlohy, pravdepodobne nie je vhodné zacínat' na nejpracovat' s vedomím, že budeme prerušený. Mali by sme si vybrat' nejakú inú. Toto kritérium teda môžeme považovat' tiež za limitujúce. 3. Dostupná energia. Sú veci, do ktorých sa netreba púšťať, ak nie sme plne sústredení. Naopak existujú úlohy, ktoré môžeme spravit' ajunavení, a nic nepokazíme. 4. Priorita. Rôzne úlohy majú rôznu prioritu. Tu ale neexistuje nijaké pravidlo v metodike, ktoré by nám povedalo, ktorá úloha má vyššiu prioritu. Je teda kompletne na nás ako si vyberiem, pokial' sú dve úlohy vykonatel'né v kontexte kde sa nachádzame, máme na ne dostatok casu, a potrebujú rovnaké množstvo energie. 8 Kapitola 3 Návrh systému Každý uživatel' má rôzne nároky na aplikáciu, ktorejzveruje organizáciu svojich úloh. GTD systémy sa snažia byt' co najviac univerzálne, aby pokryli potreby väcšiny uživatel'ov. Prílišnou univerzálnost'ou sa ale môžu dostat' do druhého extrému, a tým je zahltenie pozornosti nepotrebnými funkciami alebo informáciami. Je dôležité urciť správne množstvo poskyto-vanejfunkcionality, aby neznižovala celkovú použiteľnosť. Na rôznych platformách sa toto množstvo samozrejme bude líšit', pretože vo webovom prehľiadaä máme iné možnosti, ako v aplikácií bežiacejpod nejakým operacným systémom v pocátaä, prípadne vnútri mobilného zariadenia. 3.1 Existujúce riešenia Po prieskume najznámejších GTD softvérových riešení uvedených na akutalizovanom zozname od spolocnosti Priacta[11], som zosumarizoval vlastnosti, ktoré by mal systém obsahovat' a ktoré sú naopak zbytocné. Základnú funcionalitu majú väcšinou rovnakú: systém umožnuje pridávať rýchlo úlohy, neskôr ich organizovat' do projektov a kontextov, priraďovať im casové údaje do kedy majú byt' hotové, prípadne cas potrebný na ich vykonanie. Jednotlivé úlohy sa potom podl'a zadaných údajov dajú filtrovat', alebo rôzne radit'. Mal som možnost' pracovat' s: Remember The Milk, Nozbe, Things, Omnifocus, Wunderlist, SimpleGTD, Vitalist a Tadalist. • Webové rozhranie. Väcšinu casu pracujeme so svojimi pocítacmi, alebo aspon takými, na ktorých máme možnost' inštalovat' vlastný softvér. Niekedy ale potrebujeme vidiet' svoje dáta aj inde, a na to je vhodná webová aplikácia. Medzi jedny z najlepších GTD softvérov patria Things a Omnifocus, ktoré práve túto funkcnost' postrádajú, aj ked' možnost' kedykol'vek interagovat' so svojimi dátami nahrádzajú klientskou aplikáciu pre mobilné zariadenie. Práca s nimi však nie je ani zd'aleka tak pohodlná. • Stromová štruktúra úloh. Len máloktorý softvér obsahuje možnost' upravovat' úlohy do stromovejštruktúry, v ktorejby napríklad jedna mala niekol'ko "podúlohä tým by sa vlastne z definície stala projektom. Zo známejších programov je to napríklad Omnifocus. Jedná sa o vel'mi užitocnú funkciu, ktorá nielen zrýchľuje proces organizácie úloh, ale aj vytvára d'alši rozmer, predstavujúci ich hierarchiu. 9 3.1. EXISTUJÚCE RIEŠENIA • Mobilná veria. Telefóny majú už dnes obrovský potenciál ako platforma pre užívateľské programy. Ich veľkosť umožnuje, aby sme ich mali všade so sebou. Prinášajú tiež možnost' pracovat' s našou polohou urcenou cez GPS snímac, alebo bezdrôtové siete v dosahu. Mobilnú verziu svojich aplikácií majú napríklad už spomínaný Things a Omnifocus, d'alejRemember The Milk, Nozbe, Wunderlist atd'. • Automatické upozornenia. Niektoré informácie sú priamo spojené s urcitým casom, alebo miestom. Ked'že práve GTD nás zbavuje nutnosti pamätat' si tieto spojitosti, je dobré aby systém implementoval nejaký spôsob pripomienok v urcitom case a mieste. (Časové pripomienky sú triviálna súcast' väcšiny programov, ale v case písania tejto práce ešte neexistuje softvér, ktorý by na základe zmeny lokality uživatel'a upozornil na nejakú úlohu, ktorú v nej môže vykonat'. Tu vzniká aj motivácia vytvorit' úplne nové softvérové riešenie na tak mohutne opakovanú tému, akou je organizácia casu. • Rýchla práca so schránkou. Úlohy je nutné co najrýchejšie zadávat' do systému tak, aby nás to stálo co najmenejúsilia a casu. Dobre implementovaná schránka je teda základ pre každý GTD systém. Sú nástroje, kde je zadávanie úloh implementované vyslovene neergonomicky, ako napríklad Remember The Milk, kde sme nútení spá-jat' v metodike proces zbierania informácií s procesom organizácie a spracovania. • Prenos csových dát do iných kalendárov. L'udia majú svoje obl'úbené kalendárové aplikácie, ako ičal, kčal alebo Google Čalendar. Považujem za výhodu, umožnit' pomocou otvorených formátov prenos položiek spojených s nejakým casovým údajom, do týchto externých systémov. • Jedna úloha má mat jeden kontext. Toto pravidlo je ironicky porušované v niektorých aplikáciach prehlasujúcich sa za GTD aplikácie. Úloha má vždy priradený iba jeden kontext, v ktorom sa dá vykonat'. Ueivatel'ská potreba prirad'ovat' niektoré úlohy do viacerých z nich, vyplýva zo zlého návrhu kontextov. Ak je nejaká úloha vykonatel'ná na viacerých miestach, ako napríklad e-mail súvisiaci so zamestnaním, nemali by sme uvažovat' o kontextoch "práca"/"doma". Môže byt' vhodnejšie nie-co obecnejšie, ako napríklad „internet", vd'aka ktorému ho v skutocnosti môžeme odoslat'. • Štítky sú zbytočné. Mnoho aplikácií obsahuje podporu pre takzvané štítky. Sú to nejaké textové ret'azce, ktoré môžeme prirad'ovat' úlohám, a na základe nich potom v systéme vyhľadávať. Dôvod, preco sa štítky používajú je nedostatocná organizácia úloh do správnych kontextov a projektov, podl'a ktorých sa má dat' každá úloha jednoznacne nájst' aplikovaním rovnakejlogiky, ako pri jejzarad'ovaní. • Oznacovanie priority je zbytocné. Úlohy majú samozrejme rôznu prioritu, môžeme ju ale urcit' iba porovnaním niekoľkých úloh medzi sebou. Nemôžme povedat' vo 10 3.2. ARCHITEKTÚRA fázi organizácie, že jedna úloha má prioritu napríklad 2 a druhá 4. Neskôr ich zaradíme do iného zoznamu medzi iné úlohy, a tam už môže znamenat' priorita 2 nieCo iné. Priorita je nejaké kritérium, pomocou ktorého si vyberáme úlohy vo fázi vykonávania, a vtedy môžeme mat' iný pohl'ad na to, Co je pre nás kritické, ako poCas organizácie. 3.2 Architektúra Môjsystém sa skladá z troch castí. Sú nimi úložisko dát (server), pomocou ktorého sa synchronizujú dva typy uživatel'ských aplikácií (klienti), bežiacich v ľubovoľnom pocte inštancií. Jedná sa o webové rozhranie, a aplikáciu pre operacný systém iOS, používaný na mobilnom zariadení iPhone, iPod touch, alebo tabletoch iPad. Systém môže fungovat' samozrejme na všetkých súcastne, ked'že dáta sú aktualizované pomocou centrálnejkomponenty. Obidve aplikácie majú iné možnosti použitia, a ich spojenie vytvára plnohodnotný systém, ktorý je uživatel'ovi kedykol'vek prístupný. Architektúra systému iPhone aplikácia Webový prehliadač (r—-j) iPad aplikácia D S7 Dátové úložisko Obrázok 3.1: Schéma synchronizácie jednotlivých castí systému. Webová aplikácia nám umožnuje jednoduchú správu a organizáciu všetkých úloh, projektov a kontextov, pokiaľ máme prístup na internet. Dáta sú ihned' po modifikovaní odo- 11 3.2. ARCHITEKTÚRA sielané na server, odkial' ich môžu získavať ostatní klienti. Je možné otvoriť si webové rozhranie vo viacerých inštanciách naraz s tým, že v nich uživatel' vidí to isté. Je to akési okno umožnujúce pohl'ad na najaktuálnejšiu verziu všetkého, co sme uložili na server, pretože dáta v klientovi sa aktualizujú automaticky na pozadí v krátkych casových intervaloch, alebo pri interakcií uživatel'a. Protokol slúžiaci na synchronizáciu dát medzi klientmi a servrom je vel'mi efektívny, takže aktualizácie dát vo webovom prehliadaci prebehnú bez povšimnutia uživatel'a. Klient fungujúci na platforme ios má oproti webovej aplikácií okresané uživatel'ské rozhranie, ale zároven niekol'ko funkcí navyše. Najdôležitejšia zmena je v tom, že umožnuje uživatel'ovi pracovat' s lokálnou kópiou serverových dát, bez pripojenia na internet. od uživatel'a e vyžadovaný manuálny povel na synchronizáciu dát so servrom. Nede e sa to automaticky, pretože mobilné pripo enie môže byt' drahé, a e na uvážení ma itel'a systému, ako casto je nutné dáta aktualizovat'. Dalšia výrazná odlišnost' je práca s geografickými dátami zo snímacov polohy pomocou GPS, alebo prekladu pomocou databáze bezdrôtových prístupových bodov. Na základe týchto údajov môžeme jednotlivým úlohám nepriamo cez kontexty prirad'ovat' lokalitu, v ktorej sa dajú vykonat', a aplikácia bežiaca na pozadí nás na ne pri približení k tejto lokalite upozorní. 12 Kapitola 4 Dátové úložisko Dátové úložisko slúži ako zdrojnajaktuálnejšieho stavu dát v relacnejdatabázi, s ktorými pracuje celý systém. Umožnuje tieto dáta synchronizovat' a distribuovat' medzi jednotlivými klientmi pomocou rozhrania typu REST1, pracujúcemu nad HTTP protokolom. Je to jednoduchý webový server, využívajúci apache s modulom mod_python na svojbeh. Uživatel' sa musí na zaäatku do dátového úložiska registrovat' so svojou e-mailovou adresou a heslom. Dvojica údajov slúži na jeho autentifikáciu, po ktorejzískava kl'úc, autorizujúci všetky d'alšie operácie nad jeho dátami. Tie sú oddelené od ostatných uživatel'ov a nemôžu si ich tak medzi sebou modifikovat', ani cítat'. 4.1 Dátový model Dáta sú uložené v relacnejdatabázi, ktorá najlepšie popisuje závislosti jednotlivých entít medzi sebou. Entity predstavujúce dáta zobrazované v klientoch sú 4, no v každom type klienta sa používa iná podmnožina ich atribútov. Webové rozhranie napríklad nepoužíva geolokacné informácie k jednotlivým kontextom, a verzia klienta pre iOS nepoužíva stromovú organizáciu úloh atd'. Entita Context, reprezentuje kontexty v ktorých sa nachádzame, teda závislosti vykonávania úloh. Tie môže špecializovať viacero geografických lokalít, predstavovaných entitou ContextLocation. Entita Project, popisuje najvyššiu úroven projektov, co sa týka GTD metodiky. V kapitole 3 som spomínal, že je vhodná stromová štruktúra na organizáciu úloh, takže projekty môžu byt' reprezentované aj úlohami, a to tak, že úloha môže mat' niekol'ko potomkov v urcitejhierarchii. Záznam popisujúci úlohu entitou Action, môže mat' jeden projekt, jeden kontext a jedného rodica. Tu môže vzniknúť urcitá nekonzistencia. V databázi môže mat' úloha rodica pod iným projektom ako ten, v ktorom sa nachádza sama. Vtedy je vo všetkých klientoch dominantné zaradenie k projektu, ale kód programu by nemal dovolit' vytvoriť takúto nekonzistenciu. Je to kompromis medzi jednoduchým, výkonným kódom pracujúcim s dátami, a striktným návrhom. Všetky entity obsahujú trojicu tých istých atribútov, ktoré pomáhajú dáta medzi sebou jednoznacne identifikovat', alebo ich synchronizovat' medzi klientami. Patrí medzi ne unikátny identifikátor každého záznamu id. Dalejatribút deleted, oznacuje dva stavy záznamu, 1. REST (ang. Representational State Transfer) - architektúra rozhrania, používaná na distribúciu dát pomocou bezstavového protokolu HTTP. [2] 13 4.2. PYTHON A DJANGO či je zmazaný, alebo nie. Aj tento stav musíme ukladať, aby sa pri vymazaní dal preniesť do inýčh klientov, a až po určitej dobe vymazať úplne. Atribút updated, označuje kedy bol záznam naposledy modifikovaný. Pri synchronizácií si tak každý klient pýta od úložiska iba záznamy, ktoré boli zmenené od poslednej synchronizácie. J Project ▼ f id INT(11) updated DATETIME O user_id INT(11) deleted TINYINT(1) ^name VARCHAR(1024) -H--1 User f id INT(11) updated DATETIME ✓ name VARCHAR(64) ^surname VARCHAR(64) ^ email VARCHAR(128) email_authorized TINYINT(1) O registered DATETIME password VARCHAR(128) K_} Action 9 id INT(11) ^ user_id INT(11) updated DATETIME deleted TINYINT(1) O name VARCHAR(1024) Oproject_id INT(11) 0 context_id INT(11) ^done TINYINT(1) ^estimated INT(11) reminder INT(11) reminder_sent TINYINT(1) Oparent_id INT(11) due_date DATETIME _j ContextLocation ▼ f id INT(11) updated DATETIME user_id INT(11) -|^ deletedTINYINT(l) \> context_id INT(11) ► longitude DOUBLE ► latitude DOUBLE Indexes 4I-------------------1 I 1 J Context í id INT(11) ___|i_ updated DATETIME Ouser_id INT(11) deleted TINYINT(1) |^ name VARCHAR(1024) color VARCHAR(6) Indexes Indexes Obrázok 4.1: Schéma databáze. Výstup vygenerovaný v programe MySql Workbench. 4.2 Python a Django Python je vysokoúrovnový programovací jazyk, ktorý umožnuje spúšťať ten istý program na vačšine dostupných platforiem. Zdrojový kód je interpretovaný počas behu programu, no pri prvom spustení sa prekompiluje do optimalizovaného bajtkódu, ktorý sa pri opakovanom spúšťaní interpretuje rýčhlejšie. [12] Tento jazyk sa stáva stále viač obľúbený v prostredí internetu, kde je kritičká rýčhlost' vytvorenia softvéru od nápadu až po fungujúči produkt. Jeho hlavná výhoda je jednodu-čhost' a vysoká abstrakčia písaného kódu, vd'aka čomu sa dá sústrediť viač na jeho funkčnú stránku, a nezaoberát' sa nízkoúrovnovou práčou s pamat'ou a podobne. V dobe, ked' sa stáva pračovná sila drahšia ako hardvér, začína byt' jeho hardvérová náročnost' zanedbateľnou nevýhodou oproti nákladom na vývoj a údržbu softvéru. 14 4.2. PYTHON A ĎJANGO Ďjango je skupina knižníc napísaných v jazyku Python, slúžiacich na rýchly vývoj komplexných webových aplikácií. [3] Projekty vytvorené pomocou Ď'anga majú architektúru MVC 2 , vd'aka comu sa dá oddelit' prezentacná vrstva dát, od aplikacnejlogiky a dátového úložiska. [3] To je hlavný dovod, preco je práve kombinácia jazyka Python a knižníc Ď'ango ideálna kombinácia na stavbu môjho úložiska dát. 4.2.1 Štruktúra projektu Projekty sú uložené v jednom adresári, ktorý sa dá vygenerovat' utilitou django-admin, obsiahnutou v inštalácií Ď'anga. Spustením príkazu django-admin startproject NázovProjektu, nám utilita vytvorí rovnako nazvaný adresár, ktorý bude obsahovat' 3 súbory: skript na manipuláciu s pro ektom manage.py, súbor s nastaveniami settings.py, a urls.py, kde sú uložené informácie o mapovaní url na pohl'ady. Ďoležité e, že súbor s nastaveniami e skript preložitel'ný azykom Python, takže nastavenia sa da ú rozumne štruktúrovat' základnými dátovými typmi ako pol'om, alebo slovníkom. Využil som to napríklad na získanie prístupového hesla k neschémovejdatabázi, ktoré je uložené v inom konfiguracnom súbore. V knižnici Ďjango je dodržiavaný takzvaný ĎRY3 princíp, takže je vhodné riadit' sa ním v celom projekte. Výhody toho konceptu sú zrejmé. Pri neskoršejmodifikácií nejakejpolož-ky je nutné upravit' ju iba na jednom mieste alebo vel'mi jednoduché dohl'adat', kde všade sa používa. 4.2.2 Objektovo-relačné mapovanie Objektovo-relacné mapovanie, vacšinou oznacované skratkou ORM, obecne vytvára rozhranie medzi triedami programovacieho jazyka, a databázovým systémom. V Ďjangu zadefinujeme jednotlivé triedy reprezentujúce entity a ich vzt'ahy v relacnejdatabázi. Ako príklad uvediem triedu ContextLocation, reprezentujúcu množinu geolokacných informácií k jednotlivým kontextom. Všetky entity musia byt' podedené od triedy Model, z modulu django.db.models. Tá vytvára rozhranie medzi kódom v Pythone, a databázou. Stará sa o filtrovanie dát pri cítaní, ich ukladanie, a celkovo o generovanie SQL príkazov odpovedajúcim manipulácií s objektovou reprezentáciou dát. class ContextLocation(models.Model): updated = models.DateTimeField(default=datetime.now) user = models.ForeignKey(User) deleted = models.BooleanField(default=False) context = models.ForeignKey(Context, blank=True, null=True) longitude = models.FloatField() latitude = models.FloatField() 2. "MVC je softvérová architektúra, která rozdeľuje dátový model aplikácie, užívateľské pohl'ady a riadiacu logiku do troch nezávislých komponent tak, že modifikácia niektorej z nich má minimálny vplyv na ostatné."[9] 3. ĎRY (ang. Ďont Repeat Yourself) - skratka oznacujúca princíp stavby systému, kde žiadna informácia alebo znalost', nie je definovaná na viacerých miestach naraz.[3] 15 4.2. PYTHON A DJANGO Trieda zadefinovanejentity obsahuje atribúty, ktoré musia byt' podtrieda dátového typu Field z rovnakého modulu ako Model. Od tohoto dátového typu sú odvodené ich špecializácie, napríklad celé cisla, atributy reprezentujúce dátum a tak d'alej. Trieda field obsahuje logiku, ako jednotlivé dátové typy uložit' do konkrétneho databázového systému, a ako ich odtial' získat' a pretransformovat' na ich ekvivalenty v jazyku Python. Jedna z takýchto dátových špecializácií triedy Field je ForeignKey, ktorou popisujeme vzt'ah medzi dvomi entitami. Atribút typu ForeignKey, má ako prvý parameter triedu, na ktorú potrebujeme v databázi vytvoriť cudzí kl'úc, a zaistit' tak integritu dát pri mazaní a vkladaní. Každý atribút môžeme parametrizovat' rôznymi príznakmi, napríklad ci može byt' prázdny alebo nie. Ostatné triedy sú zadefinované podobným sposobom. Po definícií dátového modelu musíme projekt v D'angu nakonfigurovat' tak, aby sa pripojil k nejakému dostupnému databázovému servru špecifikovaním jeho adresy, a prístupových údajov v súbore settings.py. Po spustení príkazu ./manage.py syncdb v korenovom adresári projektu utilita rozpozná všetky definované entity dátového modelu, a vygeneruje odpovedajúce príkazy vytvárajúce schému databáze konkrétneho databázového servru. Aplikácia sa tak stáva prenosná na l'ubovolný databázový systém, ktorý D'ango podporuje, a tými sú: Mysql, Sqlite3, Oracle a PostgreSQL.[3] 4.2.3 Administračné rozhranie Dalšou výhodou Djanga je automatické generovanie administrcného rozhrania pomocou vstavaného modulu. Ten si pri konfigurácií do databáze uloží prihlasovacie údaje supe-ruživatel'a, ktorý potom môže definovat' rôzne správcovské skupiny, majúce prístup iba k vybraným typom záznamov. Ked'že všetky entity sú zadefinované na jednom mieste, a práca s nimi je vždy rovnaká, administracný modul vie vygenerovat' aplikáciu, v ktorejmôžeme jednotlivé záznamy pridávať, zobrazovat' alebo odstranovat'. Musíme systému iba povedat' registrovaním tried predstavujúcich model databáze pomocou metódy django.contrib.admin.site.register, ktoré z nich chceme administracnejaplikácií sprístupniť, a ako. V administracnom rozhraní sa potom zobrazí zoznam týchto entít, a pre každú z nich môžeme zobrazovat' všetky záznamy a modifikovat' ich. class ContextLocationAdmin(admin.ModelAdmin): list_display = ('id', 'user', 'updated', 'deleted', 'latitude', 'longitude') list_filter = ('user', 'updated', 'deleted') admin.site.register(ContextLocation, ContextLocationAdmin) V predchádzajúcom kóde je registrácia entity ContextLocation, s konfiguráciou urcujúcou zobrazovanie pomocou tabul'ky. V nejbudú zobrazované atribúty z n-tice list_display a bude umožnené filtrovanie záznamov podl'a položiek v zozname list_filter. Ako správca systému tak môžem napríklad filtrovat' iba záznamy konkrétneho uživatel'a, a modifikovat' ich. Väcšina webových aplikácií potrebuje podobné rozhranie na zobrazovanie obsahu databáze kôli prípadným chybám, alebo úprave obsahu. Tým, že tento problém nemusíme zakaždým riešit' znovu, sa vývoj rapídne zrýchl'uje. 16 4.2. PYTHON A DJANGO 4.2.4 Neschémová databáza Relacné databázy majú svoje výhody v dodržovaní integrity rozumne štrukturovaných dát. Na to ale potrebujú vel'ký výpoctový výkon, a pre možnost' použitia tranzakcií sa nedajú škálovat' donekonecna. Preto pre ukladanie casto používaných informácií systém využíva neschémové úložisko, do ktorého sa dajú vkladat' neštrukturované dáta identifikované nejakým ret'azcom - kl'úcom. Databázu si môžeme predstaviť ako slovník, v ktorom pre jeden textový ret'azec (kl'úc) existuje práve jedna hodnota v podobe binárneho ret'azca. Servero-vá cast' systému používa jednu inštanciu databáze Redis[13], pre ukladanie autentizažných kl'úcov, overujúcich uživatel'a pri každejoperácií nad jeho dátami. Zvyšuje sa tak priemerná priepustnost' všetkých operácií, vd'aka vysokej rýchlosti overenia uživatel'a. Narozdiel od použitia vyrovnávacej pamäte, ako napríklad memcache, je Redis perzis-tentné úložisko. Dáta sa ukladajú asynchrónne na disk, a po reštarte sa z neho obnovia. Výhoda oproti relacným databázam spocíva ajv možnosti škálovania, ked' pri náraste poctu uživatel'ov je možné jednoducho pridat' d'alšiu inštanciu Redisu, a dáta medzi všetky z nich distribuovat'. [13] 4.2.5 Mapovanie URL na pohľady Súbor projektu urls.py, obsahuje usporiadaný zoznam dvojíc zložených z regulárneho výrazu a metódy pohl'adu. Každá takáto dvojica urcuje, aká metóda sa použije na obslúženie požiadavkou s konkrétnou cestou v URL4. Jednotlivé dvojice, sa pri prijatí požiadavku na server prechádzajú v presne danom poradí. Prvý z regulárnych výrazov v nejakej dvojici, ktorý dokáže popísat' cestu z adresy požiadavku, urcí metódu ktorá ho obslúži. Napríklad z URL, ktorá má tvar http://host:port/home/ sa dá cesta home/ popísat' regulárnym výrazom Ahome/$. Mapovanie na metódu app.views.home potom vyzerá takto: (r,Ahome/$', 'app.views.home'). Vnútri výrazov môžeme špecifikovať skupiny, ktoré oznacujú nejakú konkrétnu cast ret'azca. Tieto skupiny sú potom dosadené ako d'alšie argumenty do metódy predstavujúcej pohl'ad. Argumenty do metódy v jazyku Python sa dajú dosadit' dvomi spôsobmi, a to bud' pozicne f(a1,a2,a3...), alebo pomenovaním nejakými kl'úcovými slovami f(k1=a1,k2=a2,k3=a3...). Ak je skupina vnútri výrazu pomenovaná, dosadí sa do metódy ako pomenovaný argumenty, a v prípade že nie je, dosadia sa ako pozicný, v rovnakom poradí ako sú v ceste. V nasledujúcom mapovaní sa využívajú pomenované skupiny: (r'Aapi/1.0/create(?PProject|Action|Context|ContextLocation).' '(?P(json|xml))?', 'app.api_1_0.create'), Tento regulárny výraz je v zhode napríklad s cestou /api/1.0/createProject.json, a požiada-vok prepošle do metódy ktorá je definovaná takto: 4. URL (Uniform Resource Locator) - je unikátny identifikátor špecifického tvaru, ktorý abstraktne popisuje presné umiestnenie nejakého zdroja na internete.[15] 17 4.2. PYTHON A DJANGO def create(request, entity="", dataType="json"): Prvý argument request, sa dosadí do volania vždy. Obsahuje metadáta o požiadavku, ako napríklad hlavicky z protokolu HTTP. Mapovanie na pohľady extrahuje z cesty v URL d'alšie 2 argumenty, ktoré budú pomenované entity, a dataType, s hodnotami "Projectä "json". Výsledok bude ekvivalentný volaniu create(request, entity="Project", dataType="json"). Jedna metóda môže slúžit' na vygenerovanie odpovede v obidvoch formátoch, JSON a XML, a až v kóde sa rozhodne, ktorú šablonu má použit' na základe parametru z cesty. Navyše metóda vykonáva skoro tú istú logiku pre všetky entity (uloženie, modifikácia, vytvorenie), takže ajtie sa dajú jednoducho parametrizovat'. 4.2.6 Šablonovací jazyk Django obsahuje vlastný šablonovací jazyk, prímárne urcený na transformáciu dát do nejakého iného formátu, vacšinou HTML. Dajú sa ním generovat' napríklad emaily, ktoré budú mat' na predom urcených miestach meno adresáta a podobne. V šablonách sú umiestnené znacky, za ktoré sa nahrádzajú rovnako pomenované dáta v Python slovníkoch. Šablonovací jazyk obsahuje tiež znacky popisujúce podmienky, alebo cykly a mnoho d'alších. Metóda ktorá spracováva požiadavok, vygeneruje dáta pomocou modelov, a predá ich do šablono-vacieho systému spolu so šablonou, do ktorej sa majú dosadit'. Všetky metódy dátového úložiska dokážu generovat' odpoved' v dvoch jazykoch, XML a JSON, no kód, ktorý dáta pripravuje je ten istý. Príklad šablony pre odpoved' v jazyku XML a dáta ktoré sa do nej dosádzajú: {{ message }} {% if data %} {{ data }} {% endif %} {% if status %} {{ status }} {% endif %} { "status": 200, "message": "OK", "data": 1 } D'ango má v MVC architektúre chybne pomenované tri skupiny, pohl'ady, model a ovlá-dac. Pohl'ady sú opisované ako metódy, ktoré spracovávajú požiadavky. Tie sú ale vlastne model, a pohl'ady sú v ponímaní MVC šablony. Ovládac celejaplikacnejlogiky je vlastne samotná knižnica Django, vd'aka comu je písanie aplikácií v nom tak efektívne. [3] 18 4.3. APLIKAČNÉ ROZHRANIE 4.3 Aplikačné rozhranie Pomocou mapovania URL na metódy, je popísané celé aplikaCné rozhranie dátového ulo-žiska. Cesty týkajúce sa iba rozhrania majú jednotný prefix /api/1.0/, ktorý ich odd'el'uje od ostatných pohľadov na serveri. Číslo verzie umožnuje niekedy v budúcnosti zmenit' rozhranie a rozšíriť ho bez toho, aby boli dotknutí klienti podporujúci iba jeho staršiu verziu. • api/1.0/registerUser.(json|xml) Registrácia nového uživatel'a, povinné parametre sú email a heslo. • api/1.0/createSession.(json|xml) Prihlásenie uživatel'a, vytvorí autentizacný kl'úc, autorizujúci operácie v metódach pracujúcich s dátami. Povinné parametre sú email a heslo uživatel'a. • api/1.0/removeSession.(json|xml) Odhlásenie uživatel'a, odstráni autentizacný kl'úc z databáze a znefunkcní ho tak. Povinné parametre sú session. • api/1.0/create(Project | Action| Context | ContextLocation).(json | xml) Vytvorí nový záznam pre konkrétnu entitu v databázi. Každá z nich má iné atribúty. Vráti primárny kl'úc záznamu. • api/1.0/edit(Project | Action| Context | ContextLocation).(json | xml) Upraví atribúty záznamu, ktorý je špecifikovaný primárnym kľúcom. • api/1.0/remove(Project | Action| Context | ContextLocation).(json | xml) Odstráni záznam, ktorý je špecifikovaný primárnym kľúcom. Pri zmazaní projektu sa zároven zmažú všetky úlohy, ktoré pod ním boli zaradené. Naopak pri zmazaní kontextu úlohám ktore v inom boli ostane nepriradený, zmažú sa ale geolokacné informácie s ním späté. • api/1.0/getUpdate.(json|xml) Metóda potrebuje jediný parameter, a tým je casová znacka. V databázi je pri každom zázname uložený cas, kedy bol naposledy modifikovaný. Metóda vráti všetky záznamy ktoré boli modifikované pocas, alebo po casovejznacke. Vd'aka tomu môž-mu klienti vybrat' iba tie záznamy, ktoré boli zmenené od poslednej synchronizácie. • api/1.0/iCalendar.ics Metóda vráti dokument vo formáte iCalendar, reprezentujúcom kalendárové dáta a udalosti, vhodným na ich výmenu medzi rôznymi aplikáciami.[4] Všetky záznamy ktoré majú casový údajtak môžme preniesť do externého systému. 19 4.3. APLIKAČNÉ ROZHRANIE Všetky tieto metódy potrebujú klienti na to, aby si medzi sebou vymienali dáta, alebo len zmeny. Pomocou tohoto rozhrania je možné kedykol vek vytvorit novú aplikáciu na l'ubovolnejplatforme. Podl'a platformy je možné sa rozhodnúť, ktorý výstupný formát sa na nřej lepšie spracováva a ten použit . V javaskriptovom kóde to bude pravdepodobne JSON, no v iných prípadoch môže byt' jednoduchšia práca s formátom XML. Metódy vracajú rôzne návratové kódy a správy v závislosti na tom, cři bola operácia úspešná, alebo nie. Klient sa podl a nich musí zariadit , a zobrazit uživatel ovi v prípade chyby patricřné upozornenie, alebo priamo návratovú správu popisujúcu problém. 20 Kapitola 5 Webová aplikácia Na webovú aplikáciu boli kladené vysoké požiadavky. Registrácia je práve v nej, takže je to prvá vec, s ktorou sa uživatel' stretne pri práci s celým systémom. Dojem, aký na inom zanechá ho bud' donúti študovat' d'alej jeho možnosti, alebo ho jednoducho opustí a s vel'-kou pravdepodobnost'ou nikdy nenavštívi znovu. Celá sada aplikácií je navrhnutý tak, že väcšinu casu s nou strávi uživatel' práve vo webovom rozhraní. Skladá sa iba z dvoch uživatel'ských pohl'adov, z registrácie a samotnej pracovnej plochy, kde uživatel' modifikuje a zobrazuje svoje úlohy. Obidve z nich sú vo svojejpodstate oddelené Javaskriptové aplikácie. To znamená, že pri otvorení stránky sa nacíta jejzáklad, spolu s javaskriptovým kódom. Ten sa starajá o všetku interakciu s uživatel'om, reprezentáciu dát v prehliadaci, a interpretuje ich úpravy pomocou aplikacného rozhrania do úložiska dát cez asynchrónne spúšťané požiadavky technológie AJAX. 5.1 Uživatel'ské rozhranie a vizuálny koncept Pri návrhu webovejstránky som sa snažil zosúladiť jejúcel s dizajnom. Rozvrhnutie stránky, ako ajvýber písma a farieb pre rôzne typy informácií sú rovnako dôležité nielen pre cistý a prijemný vzhl'ad, ale ajúcel samotnejprezentácie v prehliadaci. Po zhrnutí všetkých dôležitých funkcí a údajov, ktoré by uživatelia takéhoto systému mohli potrebovat', bolo potrebné vymysliet' ako tieto údaje prehľadne prezentovat' pomocou toho, co ponúka internetový prehliadac a s ním spojené technológie. Na co všetko by sme pri navrhovaní uživatelského rozhrania mali myslieť, zhrnula firma Apple v jednom z dokumentov urcených pre vývojárov aplikácií pre ich operacný systém Mac OS, nazvanom Apple Human Interface Guidlines[5]. Webové rozhranie má podobný návrh ako väcšina aplikácií pre systémy Mac OS, co umožnuje prenášať znalost' uživatelského prostredia z týchto aplikácií do mojej. V týchto programoch sme zvyknutí, že na l'avejstrane okna je panel, v ktorom zobrazujeme v stromovejštruktúre najdôležitejšie casti dokumentov. Detaily dokumentov bývajú v stredovom paneli, ktorý zaberá najväcšiu cast' plochy, a vo vrchnejcasti okna býva panel s najcastejšie používanými nástrojmi. Dôležité je analyzovat' požiadavky uživatel'ov, a zistit' ktoré casti programu sú pre nich najdôležitejšie, a co najviac im ich sprístupniť. Naopak funkcie, ktoré používajú menejcas-to, alebo iba mizivé percento uživatel'ov je vhodné skryt', aby nerozptyl'ovali pozornost'. V ideálnom prípade sa vyvíja program pomocou inkrementálneho vytvárania prototypov a ich testovania. Užitocné informácie nám ponúkne analýza chovania uživatel'ov pracujúcich 21 5.2. JAVASKRIPT A KNIŽNICA JQUERY s rozhraním prvý krát, a problémov s ktorými sa pri testovaní stretli. Tí prechádzajú vopred vymyslené scenáre vykonania nejakých úloh, a návrhár pozoruje ich postup. [5] Dnešné operacné systémy a aplikácie sú narozdiel od ich textových predchocov plné metafor. Metafory reprezentujú chovanie alebo dáta s ktorými pracujeme niecim, co ich nejako pripomína v reálnom svete.[5]. Tými môžu byt' napríklad obrázky papierových zaklada-cov na dokumenty, reprezentujúce adresáre na virtuálne dokumenty v súborovom systéme. V aplikácií má väcšina vykonateľných akcií, priradený nejaký jednoduchý obrázok, ktorý ju najviac vystihuje. Ked' potrebujeme pridat' úlohu, rýchlejšie naše oä nájdu obrázok s veľkým znakom "+"medzi ďalšími obrázkami, ako vetu "pridat' úlohu"v nejakom zozname textov. Tento scenár je tak dôležitý, že je mu vo webovom rozhraní dokonca priradená klávesová skratka. 5.2 Javaskript a knižnica jQuery JQuery je knižnica pre jazyk Javaskript, navrhnutá pre jednoduchšie písania kódu prenosného medzi rôznymi prehliadacmi. [8] Pri vytváraní kódu v cistom Javaskripte je nutné poznat' vel'ké množstvo rozdielov medzi nimi. Navyše je vel'mi pracné vytvorit' zložitejšiu aplikáciu, pre nízku úroven a abstrakciu tohoto jazyka. jQuery znižuje množstvo napísaných riadkov kódu, a ten sa stáva prehl'adnejší a lepšie spravovatel'ný. Aj menej zdatný programátor dokáže vytvoriť zložité animácie, manipulovat' s prvkami HTML dokumentu, alebo komunikovat' so serverom. Webové aplikácie tak dostávajú nový rozmer. Podobajú sa na klasické programy vnútri operacných systémov, ktoré s ním priamo interagujú. Šetria uživatel'om cas strávený nacítaním stránok, ktorých obsah sa mení jedine na strane serveru. Dôležitý prvok na strane prehliadaca je možnost' pomocou Javaskriptu odoslať požiada-vok na server. Táto technológia sa volá AJAX (Asynchrónny Javaskript a XML). Z webovej aplikácie sa stáva samostatný klient, ktorý na server prenáša iba zmeny v uživatel'ových dátach na základe jeho interakcie, a môže si tiež zmeny v nich zo servru pýtat' vo formáte JSON s ktorým vie doplnok do knižnice jQuery pracovat'. Další užitocný doplnok podporuje v jQuery šablony. Sú to kusy HTML dokumentu, do ktorých sa dosadia do predom urcených miest nejaké premenné a vzniknutý celok sa dá vpísat' do dokumentu stránky. 5.3 CSS3 Kaskádové štýly, používané v internetových prehliadacoch na úpravy vzhl'adu HTML alebo XHTML dokumentov, prešli od svojho vzniku dlhým vývojom. Samotný dokument vo formáte HTML je iba štrukturovaný text, v ktorom znackami oznacujeme jeho casti a dávame im tým rôzny význam. To ako výsledná webová prezentácia vyzerá, urcuje prehliadac pomocou kaskádových štýlov oznacovaných tiež ČSS. Zjednodušene povedané je to jednoduchý jazyk v ktorom rôznym castiam HTML dokumentu priraďujeme atribúty urcujúce ich vzhl'ad. Podpora najnovšejverzie je v dnešných prehliadacoch síce iba ciastocná, ale už celkom dostacujúca. Vo verzii ČSS3 je niekol'ko zaujímavých zmien. Ako som už spomínal 22 5.3. ČSS3 vzhl'ad funguje v súlade s úcelom, takže opíšem práve také, ktoré dodávajú môjmu systému nejakú pridanú hodnotu. Atribúty overflow-x a overflow-y, oddeľujú pri nejakejcasti dokumentu spôsob, akým sa zobrazí posuvný panel horizontálne, alebo vertikálne pokial' obsah tejto casti presiahne jeho rozmery. Umožnuje to, aby v stredovom paneli s úlohami nikdy nevznikol horizontálny posuvník, ajked' niektoré casti rozhrania skrývam mimo zobrazovanú plochu, pre ich rýchlejšie neskoršie nacítanie. Zároven sa ale zobrazí vertikálny, ked' je úloh privel'a na celú plochu. Další dôležitý atribút je text-shadow. Ten nie len vytvára príjemnejšie vyzerajúce texty, ale aj zvyšuje ich kontrast na pozadí, ktorého farbu dopredu nevieme. Kontexty majú rôzne farby, a aby boli názvy na ich farebnom podklade lepšie citatel'né, majú pod sebou tien, ktorý im robí akýsi kontrastný základ. Atribút background-size, umožnuje nastavit' obrázku pozadia prvku v HTML l'ubovol'-nú vel'kost' v závislosti na mieste, kde sa používa. Výhoda je, že jeden obrázok, reprezentujúci na viacejmiestach v inejvel'kosti tú istú metaforu, sa stiahne iba raz, a šetrí sa tak cas na prenesenie ostatných vel'kostí toho istého obrázku zo servru. Vel'kost'ou obrázku sa dá tiež vyjadrit' rôzna dôležitost' akcie, ktorú interakciou s ním vykonávame. Posledný atribút je opacity, ktorý tiež môže oddel'ovat' menej dôležité údaje od dôležitejších, ale tentokrát urcním priesvitnosti jednotlivých objektov. 23 Kapitola 6 Aplikácia pre iPhone a iPad Aplikácia pre zariadenie iPhone a iPad je najkomplikovanejšia cast' celého systému. Jejob-medzené užvatel'ské prostredie kôli malej obrazovke nahrádza fakt, že telefón máme naroz-diel od pripojenia k internetu vždy pri sebe. V prípade núdze sa snaží aplikácia poskytnút' co najviac pohodlia pre organizáciu úloh. Pri zadefinovaní geografickejpolohy ku kontextom sama upozornuje na možnost' vykonat' úlohy spojené s konkrétnym miestom, takže pridáva d'alší nástrojako odl'ahcit' našu hlavu od rôznych povinností. 6.1 iPhone, iPad a operačný systém iOS Firma Apple je autorom mnohých prelomových technológií na poli operacných systémov a hardvéru. Ich výrobky sú obl'úbené pre svoju jednoduchost', dobrý vzhl'ad a sú známe vysokou kvalitou spracovania. V roku 2007 vydala táto spolocnost' svoje prvé mobilné zariadenie nazvané iPhone, sprevádzané hudobným prehrávacom iPod touch, ktorý sa okrem absencie GSM1 a GPS2 modulu od iPhone nicim nelíši. O 3 roky neskôr, v roku 2010 vyšiel na trh d'alší prelomový výrobok, sedempalcový tablet nazvaný iPad. Vtedy bol premenovaný operacný systém fungujúci na všetkých troch typoch zariadení z už neadekvátneho „iPhone OS" na „iOS". [7] Zariadenia majú rôzne schopnosti, ale nesú so sebou prakticky ten istý operacný systém. Vzniká tak možnost' vytvárat' takzvané univerzálne binárky, ktoré sú spustitel'né na všetkých troch typoch zariadení, a až pocas spustenia sa chovajú podl'a možností, ktoré im konkrétne zariadenie poskytuje. [6] Tablet iPad má o dost' väcšiu obrazovku ako iPhone, ale stavba programového kódu pre iOS má trojvrstvú architekúru MVC (model, riadiaca logika, pohl'ad), takže pri portovaní hotovejiPhone verzie aplikácie na tablet väcšinou stací vymenit' vrstvu pohl'adu, prípadne vel'mi málo doupravit' riadiacu logiku. Majitelia môžu do svojich zariadení inštalovat' aplikácie z App Store3, ktoré predtým prešli dôkladnou kontrolou zo strany Apple. Kontrola má zabránit' vydaniu nekvalitných, alebo nedokoncených aplikácií a zvyšovat' tak spokojnosť použivatel'ov. [7] Aplikácie môžu 1. GSM (Global System for Mobile Communications) - najrozšírenejší štandard pre prenos hovorov mobilných technológií. 2. GPS (Global Positioning System) - Siet' družíc na obežnej dráhe zeme, umožnujúca presné urCenie geografickej polohy kdekoľvek na zemi. 3. App Store - služba prevádzkovaná firmou Apple, z ktorej si majitelia zariadení s operacným systémom iOS môžu vyhľadávať, a sťahovať aplikácie. 24 6.2. OBJEČTIVE-Č A ČOČOA vytvárať vývojári až po zaplatení nemalého registracného poplatku, co ešte viac odrádza neskúsených tvorcov od realizovania prvoplánových projektov bez pridanej hodnoty pre uživatel'a. Aplikácie majú len málo možnost'í, ako zasahovat' do chovania operacného systému ako takého, za co je firma kritizovaná, lebo zabranuje akejkoľvek inovácií od externých vý-vojárov. Pre niektoré nápady, ako využit' telefón a všetky jeho skutocné možnosti na nieco zaujímavé je to doslova blokujúce. Až v poslednejverzii iOS verzie 4 vydanejna jesen roku 2010, bola pridaná možnost' behu aplikácií na pozadí. [6] Takýto chod má však vel'a limitujúcich faktorov, preto musia vývojári najprv pozorne preštudovat' dokumentáciu, aby si boli istí že ich nápad sa dá zrealizovat' do fungujúcej podoby. 6.2 Objective-C a Cocoa Čocoa je súbor knižníc a vysokoúrovnových API, používaných pri vývoji aplikácií pre Mac OS X a iOS. Pridávajú možnost' natívneho vzhl'adu a chovania aplikácií s použitím malého množstva riadkov kódu. Vývojár má k dispozícií knižnice na tvorbu grafických prostredí, prácu s médiami grafikou, bezpecnost'ou, sieťovými protokolmi, databázovými systémom a tak d'alej. Dalšou mohutnou skupinou týchto API sú rozhrania pre výmenu dát medzi natívnymi aplikáciami napríklad na prácu s emailami, adresár kontaktov, alebo kalendár. [6] Programovací jazyk Objective-Č je ako názov naznacuje objektovo orientovaný jazyk, dynamicky typovaný pocas behu programu. Používa súborové prípony .h pre hlavickové súbory, a .m pre kód programu. Tento jazyk je striktná nadmnožina jazyka Č, co umožnuje kombinovat' výkonovo optimalizovaný kód s flexibilným a dobre štrukturovaným objektovým návrhom. Pridáva podporu zasielania správ medzi objektami, kde rozdiel oproti volaniu metód je preklad na ukazatel' na kód metódy sa robí pocas behu programu, a nie pri kompilácií. [10] Ako dôsledok nie je program typovo bezpecný, a môže sa prerušiť pri zaslaní správy objektu, ktorý ten konkrétny typ správy nepodporuje. Výhodou je ale polymorfizmus jazyka a dynamická väzba. Polymorfizmus pridáva silný nástrojna tvorbu univerzálneho kódu pracujúceho s vopred neznámymi dátovými typmi, a dynamická väzba pridáva možnost' pocas behu nahrávat' a uvolnovat' z pamäti casti programu. V jazyku Objective-Č je rozdiel medzi platformou Mac OS X a iOS v práci s pamät'ou. V iOS neexistuje Garbage Čollector4, takže správa pamäte je prenechaná na vývojárovi. [10] Ten musí kód organizovat' tak, aby správne poätal odkazy na objekty, pricom sa musia uvolnit' z pamäte pokial' na ne už v programe neexistuje žiadny odkaz. Pomocou nasledujúcich pravidiel sa dá jasne urciť zodpovednosť konkrétnejcasti kódu za uvolnovanie pamäte. Každý objekt má jedného, alebo viacerých vlastníkov. Pokial' sa ich pocet zníži na 0, je odstránený z pamäte. Pri zaslaní správy zacínajcejsa na copy, alloc alebo new dostaneme objekt, ktorý vlastníme. Ak by sme mu ako jeho majitel' tento pocet 4. Systém automatického čistenia pamäte vnútri operačných systémov alebo programov od objektov, ktoré už pravdepodobne nebudú nikdy použité. 25 6.3. VÝVOJOVÉ PROSTREDIE XCODE nedekrementovali potom ako s ním skoncíme prácu, nikdy nedosiahne pocet vlastníkov 0, a teda navždy ostane v pamäti a tá je stratená. Je na tejcasti kódu ktorá ho vytvorila, aby potom co s ním skoncí prácu tento pocet dekrementovala zaslaním správy release. Pokiaľ získame objekt zaslaním správy, ktorá sa nezacína na jedno z kl'úcových slov copy, alloc alebo new, musíme sa pridat' medzi vlastníkov tohoto objektu, ak s ním chceme pracovat' dlhšiu dobu. To sa robí zaslaním správy retain. [10] Operacné systémy iOS používajú takzvanú autorelease frontu na automatické dekre-mentovanie poctu vlastníkov po skoncení nejakého casového intervalu, co vedie väcšinou k odstráneniu objektu. [10] Ako vytvoriť metódu, ktorá na volajúceho neprenáša zodpovednosť za jeho uvolnenie, ale zároven má nenulový pocet vlastníkov? Objektu pred vrátením musí zaslat' správu autorelease, ktorá ho pridá do fronty pre neskoršie zaslanie správy release. Potom má pocet vlastníkov väcší ako 0, ale po case sa o jedného zníži automaticky. Treba si dat' pozor a pri dlhšom používaní týchto objektov prevziat' vlastníctvo na seba, pretože ich neskoršie uvolnenie spôsobí pád programu vtedy, ked' už dávno nevieme zistit' ktorá cast' je zan zodpovedná. 6.3 Vývojové prostredie Xcode Firma Apple je tvorcom vývojového prostredia Xcode, špecializovaného na vývojaplikácií pre ich platformy, teda Mac OS X a iOS spolu s Cocoa. Inštalácia ponúka množstvo doplnkových aplikácií ako Interface Builder na vytváranie grafických rozhraní, Shark pre profilovanie kódu, alebo Instruments na hl'adanie únikov pamäte a množstvo iných. Jedným z najdôležitejších nástrojov je iPhone Simulator, v ktorom môžeme našu aplikáciu pre iP-hone alebo iPad spustit' vo virtuálnom zariadení, a vybrat' si konkrétnu verziu operacného systému a uistit' sa, že pracuje správne. Vývojár tak nemusí vlastnit' najnovší model telefónu, ale stále má možnost' otestovat', ako na nom pobeží jeho program. Aby bol zaciatok co najjednoduchší, vývojové prostredie obsahuje niekol'ko šablón pre projekty, ktoré vytvoria kópiu jednoduchého spustitel'ného programu. Okrem šablon pre projekty sú k dispozícií ajšablony pre rôzne najcastejšie používané typy tried. Okno programu organizuje všetky súbory podl'a ich typu do rôznych skupín, a pri ich otvorení použije vhodný editor. Súbory obsahujúce informácie o grafickom rozhraní majú príponu .xib. Tieto binárne súbory sa upravujú v programe Interface Builder, kde vkladáme predpripravené grafické elementy do okna programu a nastavujeme im rôzne atribúty ako farbu, veľkosť písma a tak d'alej. Všetky tieto vkladané prvky ako tlacítka, obrázkove polia, alebo tabul'-ky, musia mat' nejakú reprezentáciu v kóde programu, aby sme k nim mohli pristupovat' a upravovat' ich vzhl'ad alebo obsah. Vnútri tohoto nástroja tak spájame vizuálne reprezentácie takýchto objektov s ich reprezentáciami v kóde programu. Tlacítkam urcíme, ktorému objektu sa má poslat' správa pri ich stlacení, tabul'kám, ktorý objekt reprezentuje zdrojich dát. 26 6.4. PROFILY NA TESTOVANIE 6.4 Profily na testovanie Každá aplikácia je podpísaná certifikátom spolocnosti Apple, a pri inštalácií do zariadení sa tento podpis overuje. Znemožnuje sa tak inštalácia aplikácií, ktoré neprešli schvaľovacím procesom a tiež ich podvrhnutie, alebo poškodenie pocas sťahovania. Existuje ale výnimka pre registrovaných vývojárov. Môžu si nechat' vygenerovat' vlastný certifikát, ktorý je unikátny pre každé zariadenie, a podpisovat' ním svoje aplikácie. IPhone simulator je dost' obmedzený, nepracuje správne s geolokacnými informáciami, alebo na stolnom pocítaci samozrejme úplne chýba podpora pre akcelerometer5. Pre dôkladné otestovanie takýchto funkcií, je nutné dostat' svoju aplikáciu do reálneho zariadenia a vidiet' ako sa v nom chová. Vo vývojovom prostredí si vyberieme, ci chceme program kompilovat' pre pripojené zariadenie alebo simulátor. V obidvoch prostrediach máme rovnaké možnosti na analýzu behu aplikácie, napríklad pozastavovanie chodu programu, cítanie lokálnych premenných v momentálne vykonávanom kóde, alebo analýzu únikov pamäte pomocou programu Instruments. 6.5 Dátové modelovanie a technológia Core Data Technológia Core Data je súcast'ou Cocoa. Obsahuje podporu pre relacné databázy a objektovo relacné mapovanie v platformách Mac OS X a iOS. Táto knižnica vytvára akúsi vrstvu medzi dátovým súborom databázového systému sqlite3 a objektovým prostredím jazyka Objective-C. Okrem pohodlnej práci so záznamami poskytuje možnost' revidovat' zmeny v dátach zhlukované po tranzakciách, väcšinou známe pod akciami „spät'" a „znovu". V XCode je vstavaný editor, v ktorom upravujeme entity databáze, a vytvárame vzťahy medzi nimi. Zmeny v schéme databáze sa dajú revidovat', takže nielen vidíme ako vyzerali predchádzajúce verzie, ale systém má natívnu podporu pre aktualizácie týchto úložísk v ap-likáciach na novšie. Pri modifikáci schémy tak pri spustení novšejverzie aplikácie systém nezahodí starú databázu, ale použije staré záznamy v nej a vytvorí s nimi novú. To samozrejme nie je jednoduchý problém, a nedá sa to vykonat' vo všetkých prípadoch. Stále je tak dost' vel'ká cast' práce na vývojárovi. Na obrázku 6.1. je výstup z editoru dátového modelu. Schéma je skoro rovnaká ako u dátového úložiska, rozdiel je v tom, že každý záznam má dva unikátne identifikátory. Jeden urcuje jeho unikátnost' v databázi na serveri, a druhý v klientovi. Pretože môžeme dáta pridávať v iPhone ajbez pripojenia, vznikajú záznamy ktoré nemajú priradený identifikátor na serveri. Ten sa potom doplní pri synchronizácií pomocou metódy v aplikacnom rozhraní s názvom „create". 6.6 Užívateľské rozhranie Na mobilnom zariadení je nutné vel'mi dobre sa zamysliet' nad tým, ktoré funkcie chceme uživatel'ovi ponúknut' a akým spôsobom. Máme k dispozícií vel'mi malý priestor na pre- 5. Akcelerometer - snímač merajúci rotáciu zariadenia v priestore, a jej zmeny. 27 6.6. UŽIVATELSKÉ ROZHRANIE Context Attributes color deleted name serverId updated ▼ Relationships If Project Attributes deleted name serverId updated T Relationships ContextLocation Attributes deleted latitude longitude serverId updated T Relationships context Action 1 Attributes deleted done due_date name serverId updated ▼ Relationships context parent project t Obrázok 6.1: Schéma databáze iphone aplikácie. Výstup vygenerovaný v programe XCode, pri dátovom modelovaní. zentáciu nejakých informácií, a je nutné týmto priestorom šetrit'. Podl'a príruCky od firmy Apple pre návrh uživatelských rozhraní, 80% uživatel'ov používa 20% funkcií v priemer-nejaplikácií. [5] Takže celé štyri pätiny uživatel'ov zaťažujeme zobrazovaním štyroch pätín funkcií, ktoré nikdy nepoužijú. Celé rozhranie je založené na komponente z knižnice UIKit, s názvom NavigationController. Ako som už spomínal v kapitole o webovejstránke, je vhodné prenášať uživatelské znalosti fungovania aplikácie medzi aplikáciami. Ak je aplikácia stavaná pomocou triedy NavigationController, bude sa vel'mi podobat' vzhl'adom ajfunkcionalitou natívnym apli-káciam zo systému iOS na správu emailu, alebo prehravanie hudby. Trieda NavigationController vytvára akýsi zásobník, do ktorého vkladáme uživatel'ské pohl'ady podl'a interakcie vo vnútri nich. Poskytuje panel nástrojov s niekol'kými automaticky generovanými tlacítkami, napríklad na odstránenie pohl'adu zo zásobníku. Úvodné menu je prvý pohl'ad vložený do zásobníka, v inom teda ovládac nezobrazí tlaätko „spät'". Ak ale prejdeme z hlavného menu do pohl'adu v ktorom vkladáme novú úlohu, ovládac automaticky zmení horný nadpis na paneli nástrojov, a vytvorí na nom tlacítko ktoré nás vráti spät'. Každý pohl'ad je podtrieda triedy UlViewController, ktorá sa o všetko stará. V podtriede potom definujeme pole tlacítok do spodného panelu, názov pohl'adu v hornom paneli a 28 6.7. GEOLOKACNÉ DÁTA podobne a rodic tejto triedy sa postará o ich správne zobrazenie. Všetky pohl'ady okrem nastavení prihlasovacích údajov obsahujú tabul'ku, ktorá je vždy trochu inak nakonfigurovaná. Úvodné menu je tiež tabul'ka, ale na rozdiel od zobrazení úloh už napríklad neposkytuje možnost' posúvat' jej obsah smerom hore a dole. Tabul'ky potrebujú na svoje zobrazenie zdroj dát. Vd'aka dynamickej väzbe to môže byt' akákoľvek trieda, ktorá implementuje protokol s názvom UITableViewDataSource. Protokol je v jazyku Objective-C akási náhrada za rozhrania. Pomenuváva sa nim nejaká množina metód, ktorú môže alebo nemusí implementovat' trieda. Potom sa dá povedat', že nejaká trieda splna konkrétny protokol alebo nie, a podl'a toho zobrazit' upozornenie pri kompilácií. Tabul'ka si od svojho zdroja dát vypýta pomocou jednejsprávy pocet sekcií v nej. Pre každú sekciu si vypýta názov, a pocet záznamov vnútri. Potom ako vie pocet záznamov, za-cne si pre ne pýtat' jednotlivé bunky, ale iba tie, ktoré nutne potrebuje zobrazit'. Pri tabul'ke ktorá má tisície záznamov sa tak vygenerujú iba tie, ktoré sú viditeľné. 6.7 GeolokaCné dáta Od vzniku iOS verzie 4 je možné nechat' spustené aplikácie na pozadí. Majú ale iba vel'mi krátku dobu na reakciu zaslanú od operacného systému, a po tejchvíli budú zase zastavené. Aplikácie bežiace na pozadí musia mat' nastavený príznak pred kompiláciou v zozname svojich vlastností. Pre položku UIBackgroundModes sa dajú doplnit' tri rôzne možnosti, preco má aplikácia bežat' na pozadí, a podl'a toho bude prebudená od operacného systému v špecifických intervaloch, na špecifický cas. V mojom príápade sú to geolokacné služby, ale aplikácia môže na pozadí bežat' aj z dôvodu prehrávania zvuku, alebo prevádzkovania VoIP hovorov. [6] Zariadenie iPhone môže svoju polohu urciť pomocou troch spôsobov. Má v sebe stavaný GPS snímac, ktorým ju urcí s presnosťou na jednotky metrov, ten je ale najviac nárocný na spotrebu energie z batérie. Druhý najpresnejší spôsob je na základe prekladu identifikátora bezdrôtovej siete na jeho polohu. Presnost' je tu v desiatkách metrov, v závislosti na vzdialenosti od prijímaca. Posledná, najmenejpresná metóda využíva bunky GSM siete na urcenie svojejpolohy. Cím bližšie sa prijímac nachádza od vysielacou tým je metóda presnejšia, ale obecne ide o stovky metrov až desiatky kilometrov. [6] Získavanie polohy sa zacína registrovaním jejprijímania pomocou triedy CLLocation-Manager. Urcíme požadovanú presnosť, a objekt, ktorý má zmeny polohy dostávat'. Ten v intervaloch ktoré urcí operacný systém prijíma pomocou protokolu CLLocationManager-Delegate zmeny polohy, a v zariadení ktoré má vstavaný kompas aj zmeny smeru. [6] Od-porúcaná je možnost' zaregistrovat' sa iba k významným zmenám polohy, ktorá sa zisťuje na základe GSM buniek. Aplikácia sa tak budí jedine pokial' uživatel' robí vel'ké pohyby spolu so zariadením. Túto možnost' som samozrejme využil, pretože použitie GPS snímaca by bolo prehnané. Pokial' operacný systém má možnost' svoju polohu upresniť bez d'alšejnámahy, tak to urobí, preto objektu ktorý je registrovaný na príjem polohy posiela aj informáciu o jej od-hadovanejpresnosti. Napríklad ak je zadefinovaná jedna lokalita doma, kde je bezdrôtový 29 6.7. GEOLOKAČNÉ DÁTA vysielac, pri pripojení nan je poloha spresnená a aplikácia dostane vel'mi presný údaj. Vd'a-ka tomu môže byt' upozornený na úlohu vykonatel'nú doma hned' ako sa dostane na dosah známeho bezdrôtového prístupového bodu. 30 Kapitola 7 Záver Zadanie sa podarilo splnit', bola dokoncená fungujúca implementácia celého systému pozostávajúceho z troch komponent. Prínos pre uživatel'a je ešte väcšia voľnosť pri organizácií svojho casu, kedy ho systém podl'a jeho polohy zaznamenanejz mobilného zariadenia upo-zornuje na úlohy späté s konkrétnym miestom. Samozrejmosťou je, že sada aplikácií slúži ako plnohodnotný systém, ktorý splna všetky predpoklady na organizáciu casu a práce pomocou metodiky GTD. V prílohe sú zdrojové kódy pomerne komplexnejaplikácie pre operacný systém iOS, ktorý môže zacínajúcemu vývojárovi poskytnúť reálnu a užitocnú ukážku ku ktorejsa len t'ažko dostane z iných zdrojov. Všetky použité technológie sú pomerne nové, takže sa k nim dá dostat' casto jedine samoštúdiom. Ked'že nie som vlastníkom zariadenia iPhone, ale len iPod Touch, nepodarilo sa mi celkom presne otestovat' získvanie geolokacných dát na základe GSM buniek, ale iba bezdrôtových sietí. Modulárnost' systému a presne definované rozhrania medzi komponentami umožnujú implementáciu klientov pre d'alšie platformy, v com budem urcite pokracovat'. Vytvorené zdrojové kódy sú dost' rozsiahle, ale vel'mi dobre organizované, co je kritické pre d'alšie po-kracovanie. Potreby používateľov sa stále menia, preto rýchlosť vývoja je rovnako dôležitá ako jednoduchost' údržby celého systému. 31 Literatúra [1] Introduction to CSS3, 2010, . [2] Fielding, R.: Architectural Styles and the Design of Network-based Software Architectures, 2000, . 1 [3] Django documentation, 2010, . 4.2, 3, 4.2.2, 4.2.6 [4] Internet Calendaring and Scheduling Core Object Specification, 2009, . 4.3 [5] Apple Human Interface Guidlines, 2010, . 5.1, 6.6 [6] iOS Reference Library, 2010, . 6.1, 6.2, 6.7 [7] iPhone, 2010, . 6.1 [8] jQuery, 2010, . 5.2 [9] Model-View-Controller, 2010, . 2 [10] Introduction to The Objective-C Programming Language, 2010, . 6.2 [11] GTD Software Comparison Table, Priacta. inc, 2010, . 3.1 [12] Python Programminglanguage, 2010, . 4.2 [13] Redis, 2010, . 4.2.4 [14] Allen, D.: Getting Things Done: How to achieve stress-free productivity, Piatkus Books, London, 2004, ISBN 978-0-7499-2264-1. 1.1, 1.2, 2, 2.1.1, 2.1.2, 2.1.3.1, 2.1.3.2, 2.1.3.3, 2.1.3.4,2.1.4 [15] RFC 1738 - Uniform Resource Locators (URL), 2010, . 4 32 Dodatok A Obrazové prílohy Obrázok A.1: Stromova štruktúra úloh 33 A. OBRAZOVÉ PRÍLOHY Obrázok A.2: Detail vybraného projektu 34 A. Obrazové prílohy 35 A. Obrazové prílohy 36 A. OBRAZOVÉ PRÍLOHY Django administration Welcome, root. Change password / Log out Obrázok A.5: Administracné rozhranie, výpis filtrovaných záznamov Obrázok A.6: Administracné rozhranie, detail záznamu 37 A. Obrazové prílohy Obrázok A.7: Zobrazené dva pohľady v iOS aplikácií. Úvodné menu vl'avo, a vloženie novej úlohy vpravo. 38 Dodatok B Obsah CD Priložené ČD obsahuje • text práce so zdrojovým súborom vo formáte docbook • zdrojové súbory klienta pre operacné systémy iOS • zdrojové súbory dátového úložiska • zdrojové súbory webového klienta 39