Fotografický magazín "iZIN IDIF" každý týden ve Vašem e-mailu.
Co nového ve světě fotografie!
Zadejte Vaši e-mailovou adresu:
Kamarád fotí rád?
Přihlas ho k odběru fotomagazínu!
Zadejte e-mailovou adresu kamaráda:
Informace
Programování pro iOS - 5. Rámce a jejich řídicí objekty
1. září 2010, 00.00 | Vylepšujíce postupně naši aplikaci pro zjištění vzdálenosti bouře, dostáváme se ke zobrazení záznamů z historie. Využijeme k tomu překryvného rámce; zčásti proto, že je to celkem rozumné, a hlavně proto, abychom se s těmito rámci naučili pracovat.
Hierarchická struktura rámců ("views") v oknech pro nás není žádnou novinkou; seznámili jsme se s ní již dávno, a v podstatě platí pro iOS stejně, jako pro Mac OS X (ačkoli se samozřejmě třída, jejíž instance rámce reprezentují, jmenuje UIView namísto NSView). Konkrétní použití se ale do jisté míry liší.
V Mac OS X je obvykle zastřešujícím objektem pro hierarchii rámců, reprezentující nějaký samostatný prvek grafického uživatelského rozhraní aplikace – inspektor, paletu, konkrétní editor apod. – okno. Má-li takovýto prvek vůbec samostatný vlastní řídicí objekt (a není-li řízen spolu s jinými prvky), je obvykle právě na úrovni okna jako celku. Naopak v Mac OS X se jen málokdy setkáváme s hierarchií rámců, jež není uložena v nějakém okně, a/nebo jež by měla samostatný řídicí objekt (ačkoli obojí je samozřejmě možné, a složitější aplikace toho občas využívají).
V iOS je naproti tomu standardně v celé aplikaci pouze jediné okno, a jeho postavení je velmi okrajové – jen málokdy má jiné postavení, než sloužit jen jako pozadí, v němž se podle potřeby střídají různé rámce, reprezentující grafické uživatelské rozhraní. Hierarchie rámců, reprezentující samostatné prvky GUI – inspektory, palety, apod. – tedy jsou vždy zastřešeny svým kořenovým rámcem, jehož rozměry typicky odpovídají rozměrům obrazovky; tento rámec má takřka bez výjimky vlastní samostatný řídicí objekt.
Součástí knihovních služeb UIKitu pak jsou specializované "složené" řídicí objekty, jejichž úkolem je spravovat skupiny řídicích objektů rámců a prezentovat je standardizovaným způsobem uživateli.
Určující zde je právě to, že primární je řídicí objekt (který má nějaký rámec); kupříkladu třída UINavigationController reprezentuje hierarchickou skladbu řídicích objektů, z nichž každý další obvykle reprezentuje "detailnější" pohled na některý prvek z předchozího, a kde se můžeme podle libosti vracet – dobrým příkladem je třeba uživatelské rozhraní standardní aplikace "Settings". UINavigationController nepracuje přímo s rámci, v nichž je uživatelské rozhraní uloženo; pracuje s jejich řídicími objekty, a k rámcům přistupuje pouze jejich prostřednictvím.
Pro srovnání, v Mac OS X tomu typicky bývá opačně: tam obvykle máme rámec (např. NSTabView), který spravuje primárně podřízené rámce; ty mohou (ale nemusí) mít vlastní řídicí objekty. Přibližným ekvivalentem v UIKitu je UITabBarController; ten však primárně spravuje podřízené řídicí objekty (z nichž každý samozřejmě má vlastní rámec).
Vidíme tedy, že v iOSu je struktura poněkud rigidnější: tam, kde se v Mac OS X můžeme volně rozhodnout, zda pro rámec určit vlastní řídicí objekt nebo zda z jediného společného řídicího objektu spravovat několik různých rámců, mnohdy v iOS nemáme na vybranou.
Zobrazení historie
Ukažme si to celé v praxi v souvislosti s naší aplikací pro odhad vzdálenosti bouřky: v minulém dílu jsme v ní implementovali paměť pro minulá měření; nyní přidáme překryvné "okno" (ve skutečnosti tedy rámec, jak víme, vše v aplikaci probíhá uvnitř jediného společného okna) s tabulkou, v níž budou jednotlivá měření zobrazena.
Zatímco v Mac OS X bychom patrně tuto tabulku umístili do samostatného okna bez vlastního řídicího objektu – řídicím objektem by pro ni byl náš MainViewController –, v iOS by to šlo těžko nebo vůbec. Zde místo toho potřebujeme nový řídicí objekt, dedikovaný pouze pro správu nového rámce s tabulkou. Protože takové řídicí objekty jsou poměrně časté, UIKit pro ně dokonce standardně nabízí specialisovanou třídu, UITableViewController.
V Xcode si proto vyžádáme vytvoření nového souboru – nejlépe asi ve skupině "Main View", kam to celé logicky patří; alternativně můžeme vytvořit skupinu novou – pomocí kontextové nabídky "Add / New File..." (nebo některé z alternativních služeb). V panelu pro specifikaci souboru pak vybereme "iPhone OS / Cocoa Touch Class / UIViewController Subclass", a označíme přepínače "UITableViewController subclass" a "With XIB for user interface". Nazvat jej můžeme třeba "HistoryViewController".
Tím jsme si ušetřili poměrně dost práce: nejenže za nás projektový vzor v Xcode sestavil kostru potřebného zdrojového souboru, obsahující řadu potřebných metod, jejichž kód nám tedy stačí pouze doplnit; navíc jsme "zadarmo" dostali soubor "HistoryViewController.xib", obsahující kompletní objektovou síť – tedy požadovanou tabulku (instanci rámce UITableView) spolu se všemi potřebnými objektovými vazbami mezi ní a naším řídicím objektem (ten je samozřejmě reprezentován v objektové síti jako "File's Owner").
Zbývají nám dva úkoly:
- v řídicím objektu hlavního rámce nový kontrolér (a jeho prostřednictvím tedy také jeho rámec) zobrazit, pokud si uživatel vyžádá zobrazení neprázdné historie;
- ve třídě HistoryViewController zobrazení minulých měření v tabulce skutečně zajistit. Tím začneme.
Zobrazení dat v tabulce
Možnosti třídy UITableView jsou poměrně bohaté; umožňují zobrazení řady dynamických datových struktur, od poměrně jednoduchých tabulek jakou je např. seznam přijatých zpráv v aplikaci Mail, až po skupiny odkazů podobného typu, jaké známe třeba z aplikace Settings. Atributy, vzhled, formát i konkrétní obsah rámce jsou určeny pomocí standardizovaných služeb delegáta a datového zdroje; neurčíme-li jinak, je standardně delegátem i datovým zdrojem tabulky, vytvořené výše popsaným způsobem, její řídicí objekt. Stačí tedy otevřít soubor "HistoryViewController.m", a vše potřebné do něj doplnit.
Nejprve si musíme zajistit přístup k historii samotné; zde je samozřejmě spousta možností, ale asi nejběžnější je do řídicího objektu doplnit odkaz na nadřízený řidicí objekt – v našem případě tedy na instanci třídy MainViewController – a z něj si vše potřebné načíst. To by mohlo vypadat kupříkladu takto:
// HistoryViewController.h
...
#import <UIKit/UIKit.h>
@class MainViewController;
@interface HistoryViewController:UITableViewController {
MainViewController *delegate;
}
-initWithDelegate:(MainViewController*)del;
@end
Proč používáme direktivu @class namísto přímého importu hlavičkového souboru "MainViewController.h"?
Pak již můžeme implementovat vše potřebné – většinu následujícího zdrojového textu již máme hotovou díky projektovému vzoru; doplníme jen metodu initWithDelegate: a několik zbývajících drobností:
// HistoryViewController.m
...
#import "HistoryViewController.h"
#import "MainViewController.h"
@implementation HistoryViewController
-initWithDelegate:(MainViewController*)del {
if (!(self=[super initWithStyle:UITableViewStylePlain]))
return nil;
delegate=del; // delegát se "neretainuje"
return self;
}
...
-(NSInteger)numberOfSectionsInTableView:tv {
return 1;
}
-(NSInteger)tableView:tv numberOfRowsInSection:(NSInteger)s {
return delegate.history.count;
}
-(UITableViewCell*)tableView:(UITableView*)tableView
cellForRowAtIndexPath:(NSIndexPath*)indexPath {
static NSString *CellIdentifier = @"Cell";
UITableViewCell *cell=[tableView
dequeueReusableCellWithIdentifier:CellIdentifier];
if (!cell)
cell=[[[UITableViewCell alloc]
initWithStyle:UITableViewCellStyleValue1
reuseIdentifier:CellIdentifier] autorelease];
NSDictionary *d=[delegate.history
objectAtIndex:indexPath.row];
cell.textLabel.text=[NSString
stringWithFormat:@"%.1 f km",
[[d objectForKey:@"dist"] doubleValue]/1000.];
cell.detailTextLabel.text=
[[d objectForKey:@"timestamp"] description];
return cell;
}
...
Tabulky v iOS, jak vidíme, zdaleka nejsou pro programátora tak pohodlné jako v Mac OS X – chybí bohužel podpora "bindings" a musíme explicitně programovat datový zdroj, podobně jako před nějakými deseti lety. Základní princip je – jak je ostatně vidět v kódu – tento:
- tabulka může být v iOS vždy dvouúrovňová: její řádky mohou být rozděleny do několika samostatných sekcí. Jelikož toho nevyužijeme, vrátíme z metody numberOfSectionsInTableView: prostě 1 – tabulka vždy pošle nejprve svému datovému zdroji odpovídající zprávu, aby zjistila, kolik v ní bude sekcí. Mimochodem, pokud bychom neplánovali později sekcí využít, mohli bychom metodu prostě smazat: není-li součástí datového zdroje, považuje se "1" za standardní hodnotu;
- podobně metodu tableView:numberOfRowsInSection: tabulka použije ve svém datovém zdroji pro zjištění počtu řádků v každé ze sekcí. Jelikož my máme sekci pouze jedinou, nemusíme se o argument metody starat; vrácenou hodnotou je samozřejmě počet záznamů v poli s historií měření – všechny zobrazíme v prvé (a jediné) sekci;
- pro vlastní zobrazení dat slouží metoda tableView:cellForRowAtIndexPath:; kdykoli má tabulka zobrazit kterýkoli řádek, pošle svému datovému zdroji odpovídající zprávu. Metoda je trochu komplikovaná – místo toho, aby prostě vrátila objektovou hodnotu pro zobrazení (jak tomu např. bývalo kdysi dávno v Mac OS X), musí vytvořit a vrátit "buňku": speciální objekt, který reprezentuje jak vlastní hodnoty, tak i jejich požadovaný vzhled. Navíc je zapotřebí tyto objekty nevytvářet a nerušit pro každý řádek tabulky znovu, ale musíme je cacheovat. Kód pro to je naštěstí součástí projektového vzoru, takže jej můžeme prostě nechat beze změny; změníme pouze styl buňky (ve stylu UITableViewCellStyleValue1 jsou vedle sebe dva textové údaje, a přesně to nyní potřebujeme). Pak obě hodnoty do buňky zapíšeme – použijeme jejích standardních atributů textLabel a detaileTextLabel, jež oba obsahují objekty třídy UILabel – a to je vše.
Abychom se zbytečně nezabývali detaily, které na této úrovni nejsou podstatné, dovolili jsme si zjednodušení, jež by ve skutečné aplikaci určené k prodeji nebylo úplně správné: datum a čas měření zobrazujeme v "systémové" podobě, jakou získáme pomocí zprávy description; správnější by samozřejmě bylo datum přeložit do vhodného tvaru pomocí služeb třídy NSDateFormatter.
Zobrazení (a skrytí) překryvného rámce
Chceme-li zobrazit nový rámec, který dočasně překryje rámec stávající (a později umožní návrat), používáme obvykle standardní službu presentModalViewController:animated:. Příjemcem této zprávy je řídicí objekt rámce, který je v současnosti zobrazen; jejím argumentem je rámec nový (a přepínač, jehož pomocí určíme, zda se rámec má "objevit", nebo má-li využít standardní animace). V našem případě by odpovídající kód mohl vypadat například takto:
// MainViewController.m
...
#import "MainViewController.h"
#import "HistoryViewController.h"
...
-(IBAction)showHistory {
...
else
[self presentModalViewController:
[[[HistoryViewController alloc]
initWithDelegate:self] autorelease]
animated:YES];
}
...
Pro skrytí rámce slouží analogicky zpráva dismissModalViewControllerAnimated:. Tentokrát si dovolíme zjednodušení dokonce dvojí: předně, koncepčně čisté by bylo, aby rámec skrýval kód téhož objektu, který jej zobrazil – tedy kód třídy MainViewController. Správně bychom tedy měli v této třídě implementovat speciální metodu pro skrytí historie a z jejího řídicího objektu ji zavolat – podobně tomu je při skrývání "FlippedView" v kódu, který nám vygeneroval projektový vzor (vizte metodu flipsideViewControllerDidFinish: a její použití).
My si ale ušetříme práci a skrytí rámce implementujeme přímo ve třídě HistoryViewController. Navíc to uděláme tak, že využijeme standardní metody delegáta (kterou nám připravil projektový vzor), takže rámec skryje klepnutí na kterékoli políčko tabulky:
// HistoryViewController.m
...
-(void)tableView:tv didSelectRowAtIndexPath:ip {
[delegate dismissModalViewControllerAnimated:YES];
}
...
Správnější by bylo použít standardního tlačítka "Back" nebo "Done" (případně spolu s řídicím objektem UINavigationController, zvláště pokud by bylo možné pro políčka tabulky zobrazit více informací – mohli bychom třeba pro každý záznam ukládat také geografické souřadnice, umožnit jeho zobrazení v mapě apod.; možná si později některá taková vylepšení ukážeme).
Historii tedy umíme zobrazit – ale přijdeme o ni pokaždé, když aplikaci ukončíme. To není dobré, a příště se podíváme, co by se s tím dalo dělat.
Obsah seriálu (více o seriálu):
- Nastal čas na kakao...
- Tak nejdřív kakao ochutnáme...
- Programovací jazyk C: velmi, velmi stručně
- Objective C: to si vysvětlíme podrobněji
- Co jsme si o Objective C ještě neřekli...
- Nastal čas na kakao - Vznik a zánik objektů
- Nastal čas na kakao - Kopírování objektů
- Nastal čas na kakao - Skryté podtřídy
- Nastal čas na kakao - Základní služby objektů
- Nastal čas na kakao - Jak správně psát v Objective C
- Nastal čas na kakao - Jak správně importovat
- Nastal čas na kakao - Podtřídy, delegáti, vkládání, jak se to rýmuje?
- Nastal čas na kakao - Využití kategorií namísto dědičnosti
- Nastal čas na kakao - Vkládání objektů a přesměrování zpráv
- Nastal čas na kakao - Inicializace a rušení objektů
- Nastal čas na kakao - Metody initWith... a designovaný inicializátor
- Nastal čas na kakao - Inicializace: tipy a triky
- Nastal čas na kakao - Accesory: přístup k proměnným instancí
- Nastal čas na kakao - Šedá je teorie, zelený je strom života...
- Nastal čas na kakao - Více o XCode: inspektory
- Nastal čas na kakao - Aplikace RSS2: datový model
- Nastal čas na kakao - Aplikace RSS: implementace datového modelu
- Nastal čas na kakao - Aplikace RSS: parsování XML
- Nastal čas na kakao - Interface Builder a uživatelské rozhraní
- Nastal čas na kakao - Interface Builder: atributy objektů
- Nastal čas na kakao - Interface Builder: atributy objektů
- Nastal čas na kakao - Druhý kontrolér a dokončení aplikace
- Nastal čas na kakao - Drobná vylepšení a zdokonalení...
- Nastal čas na kakao - Ladění
- Nastal čas na kakao - Třídy Foundation Kitu
- Nastal čas na kakao - Třídy Foundation Kitu (2)
- Nastal čas na kakao - Textové řetězce: NS(Mutable)String
- Nastal čas na kakao - Čísla, binární data a další...
- Nastal čas na kakao - Archivace objektů
- Nastal čas na kakao - Trocha magie, aneb distribuované objekty
- Nastal čas na kakao - Málem bychom zapomněli: NSAutoreleasePool
- Nastal čas na kakao - Zpracování výjimek: NSException
- Nastal čas na kakao - NSInvocation a černá magie
- Nastal čas na kakao - Kakao v Tygrovi
- Nastal čas na kakao - Notifikace: nepřímé předávání zpráv
- Nastal čas na kakao - NSUserDefaults
- Nastal čas na kakao - Co nového ve Foundation Kitu
- Nastal čas na kakao – s Intelem, s Intelem, jedeme do...
- Co nového v Xcode
- Začínáme s AppKitem
- Jak MVC v Kakau vypadá doopravdy?
- Jak MVC v Kakau vypadá doopravdy: dokončení
- Přehled tříd AppKitu
- Nastal čas na kakao - Přehled tříd AppKitu 2
- Přehled tříd AppKitu 3: zbývající třídy GUI
- Přehled tříd AppKitu 4: textový systém
- Nastal čas na kakao - Přehled tříd AppKitu 5: hlavně grafika
- Přehled tříd AppKitu 6: dokumentový systém
- Přehled tříd AppKitu 7: dokončení
- Pojmenované vlastnosti objektů
- Pojmenované vlastnosti objektů: implementace
- Pojmenované vlastnosti objektů: relace 1:N
- Pojmenované vlastnosti objektů: řazení jmen a agregační funkce
- Sledování změn objektů
- Sledování změn objektů – ukázka
- Sledování změn objektů – zdrojový kód
- Sledování změn objektů: kód modelu
- Sledování změn objektů: přímý přístup
- Kontroléry a vazby
- Vázání vazeb
- Další vazby s jednoduchým kontrolérem
- Implementace a použití převodu hodnot
- Validace hodnot
- Validace a chyby, a jedna hezká vazba...
- Práce s polem objektů
- Základní vazby NSArrayControlleru
- Převodníky, přepínače, placeholdery
- Mírná vylepšení v mezích zákona
- Objective C 2.0 - novinky z Leoparda
- NSTreeController
- Programování v Cocoa - Pár tipů a triků
- Programování v Cocoa - Základy kreslení
- Kterak nakreslit modrý obdélník...
- Další služby pro kreslení
- Obrázky a písmenka...
- Události a myš
- Lepší práce s myší
- Události klávesnice
- Input Management
- Příkazy a schránka
- Další události
- Táhni a padni
- Byli jsme na tahu; nyní padneme.
- Zvolme si, jak vhodit
- Drobnosti a chybičky
- Speciální případy tahání či házení
- Kterak táhnout něco, co neexistuje?
- Jak na sítě...
- NSURLConnection
- Safari za minutu
- Služby WebKitu
- Kakao v Leopardu
- Druhé Objective C
- Druhé Objective C: různé drobnosti
- Druhé Objective C: kategorie a protokoly
- Druhé Objective C: nový příkaz cyklu
- Druhé Objective C: atributy a accesory
- Druhé Objective C: atributy a accesory
- 64 je dvakrát 32
- Ubicumque dulce est, ibi et acidum invenies...
- Irbis: že prý žádné novinky?
- Blok sem, blok tam, nám už je to všechno jasné...
- Bloky jsou i v AppKitu
- Irbis a Foundation Kit
- Kde jsou má data?
- Kde jsou má data? V NSCache!
- Soubor, jméno, URL, jak se to rýmuje...
- Další podpora NSURL
- Zabíjení!
- A máme tady i...OS!
- Systémové prvky GUI
- Programování pro iOS 1. díl - Rozdíly mezi "i" a "Mac"
- Programování pro iOS - 2. Začínáme programovat
- Programování pro iOS - 3. základní ovladače a propojení GUI s kódem
- Programování pro iOS - 4. Varovná hlášení
- Programování pro iOS - 5. Rámce a jejich řídicí objekty
- Programování pro iOS - 6. Ukládání dat
- Programování pro iOS - 7. Správa paměti a starý restík
- Programování pro iOS - 8. Dokončení aplikace
- Programování pro iOS - 9. Jak dostat aplikaci do iPhone
- Programování pro iOS - 10. Instalace aplikace do cizího iPhone
- Programování pro iOS - 11. Jak dostat aplikaci do libovolného iPhone
- Programování pro iOS - 12. Touching!
- Programování pro iOS - 13. Kreslíme na iPhone
- Programování pro iOS - 14. Udělejme gesto
- Programování pro iOS - 15. Další gesta
- Programování pro iOS - 16. Více prstů, více zábavy
- Programování pro iOS - 17. Podpora standardních gest
- Programování pro iOS - 18. Recognizery v iOS
- Programování pro iOS - 19. Další standardní recognizery
- Programování pro iOS - 20. Co nového v iOSu
- Programování pro iOS - 21. "Multitasking"
- Programování pro iOS - 22. Nulla est honesta avaritia nisi temporis
- Programování pro iOS - 23. Jak se aktivovat, jsme-li v pozadí
- Programování pro iOS - 24. Zbývající drobnosti
- Programování pro iOS - 25. Řídicí objekty rámců
- Programování pro iOS - 26. Jak se dělá UIViewController
- Programování pro iOS - 27. Kde vzít rámce
- Programování pro iOS - 28. Základní služby
- Programování pro iOS - 29. Práce s rámci
- Programování pro iOS - 30. Rotace zařízení
- Programování pro iOS - 31. Správa paměti v rámcích
- Programování pro iOS - 32. Řídicí objekt pro tabulky
- Programování pro iOS - 33. Řídicí objekt pro strom
- Programování pro iOS - 33. Více o UINavigationControlleru
- Programování pro iOS - 35. Ještě jednou UINavigationController
- Programování pro iOS - 36. Po navigátoru taby
- Programování pro iOS - 37. Více o UITabBarControlleru
- Programování pro iOS - 38. Dokončení UITabBarControlleru
- Programování pro iOS - 39. UIPopoverController
- Programování pro iOS - 40. Další triky UIPopoverControlleru
- Programování pro iOS - 41. Zbývající služby UIPopoverControlleru
- Programování pro iOS - 42. UISplitViewController
- Programujeme v
iTunesXcode 4 - Programování pro iOS - 44. Předvolby Xcode 4
- Programování pro iOS - 45. Práce v Xcode 4
- Xcode 4: projekt a cíle
- Xcode 4: práce s cíli
- Xcode 4: Build Settings
- Xcode 4: Build Phases
- Xcode4: Build Phases podruhé
- Xcode 4: Co jsou to Build Rules?
- Xcode4: taje editoru
- Xcode4: automatické doplňování v editoru
- XIBy chyby
- Více o XIBech
- Editor XIBů
- Inspektory pro XIBy
- Vazby mezi objekty v XIBech
- Vazby mezi objekty v kódu
- Paletky Xcode pro XIBy
- Xcode 4: levý sloupec
- Xcode 4: okno Organizer
- Xcode 4: okno Organizer, část druhá
- Xcode 4: co je to Workspace?
- Xcode 4: základy schémat
- Xcode 4: akční schémata
Diskuse k článku
Vložit nový příspěvek Sbalit příspěvky
|
|