Programování pro iOS - 36. Po navigátoru taby - MujMAC.cz - Apple, Mac OS X, Apple iPod

6. dubna 2011, 00.00 | V minulém pokračování našeho seriálu, věnovaného programování aplikací v iOSu, jsme dokončili povídání o třídě UINavigationController; dnes budeme pokračovat další obecnou třídou, UITabBarControllerem.

Koncepce, princip použití a služby třídy UITabBarController se, jak uvidíme, dost podobá UINavigationControlleru, jehož popis jsme minule dokončili:

• oba jsou "kontejnery", jež obsahují sadu dalších řídicích objektů, podle potřeby mezi nimi přepínají a zobrazují jejich rámce;

• oba do obrazovky doplní své vlastní uživatelské rozhraní (záhlaví nahoře u UINavigationControlleru, taby dole zde);

• pro oba je k dispozici velmi podobné podpůrné API hned na obecné úrovni třídy UIViewController;

• oba využívají pomocný objekt přiřazený každému z obsažených řídicích objektů pro doplnění potřebných informací (pro UINavigationController to byl UINavigationItem, zde se zanedlouho seznámíme s podobnou třídou UITabBarItem);

• oba dokáží podobným způsobem spolupracovat s delegátem (ačkoli zde, jak uvidíme, UITabBarController umí ještě leccos navíc);

• nakonec se můžeme zmínit i o tom, že oba dokáží využít a zobrazit standardní titulek řídicího objektu (tedy obsah jeho atributu title), ačkoli to už je spíše drobnost.

Hlavním rozdílem mezi řídicími objekty UITabBarController a UINavigationController je to, že rámce spravované UITabBarControllerem jsou si rovnocenné, není mezi nimi žádná hierarchická návaznost. Proto také uživatelské rozhraní umožňuje volně přepínat z kteréhokoli z nich na kterýkoli jiný – ne jen na "předchozí", jako tomu bylo u navigátoru.

Služby třídy UITabBarController jsou obecně bohatší a nabízejí více možností (a také ušetří programátorovi více práce, pokud jde o podporu standardních aplikačních služeb).

Princip funkce

Základní princip, na němž je funkce "tab-baru" založena, můžeme téměř doslova opsat z článku o navigátoru, jen s drobnými změnami:

• instance třídy UITabBarController je standardním řídicím objektem rámce – můžeme jej tedy např. kdykoli zobrazit nad stávajícím rámcem pomocí služby presentModalViewController:animated: apod. Velmi často bývá hlavním řídicím objektem celé aplikace; pak je jeho kořenový rámec prostě v metodě application:didFinishLaunchingWithOptions: umístěn do hlavního okna;

• jeho rámec zobrazuje standardní zápatí ("taby") a nad ním libovolný vnořený řídicí objekt – může to být třeba i navigátor, o němž jsme si povídali v několika předcházejících dílech našeho seriálu, nebo cokoli jiného (naopak ale "tab bar" do navigátoru se nevkládá, protože by to bylo pro uživatele matoucí);

• takovýchto vnořených řídicích objektů může "tab bar" obsahovat více; zobrazuje vždy jeden z nich, a jeho zápatí ("taby") automaticky zajišťuje možnost přepnout na kterýkoli jiný.

Řídicí objekt třídy UITabBarController tedy používáme v aplikacích, které nabízejí několik různých služeb (nebo několik různých pohledů na společná data). Každou takovou službu (nebo pohled) implementujeme jako samostatný řídicí objekt rámce – na rozdíl od řídicích objektů uvnitř UINavigationControlleru bývají typicky tyto řídicí objekty navzájem odlišné –, a tyto řídicí objekty pak "zastřešíme" společným UITabBarControllerem.

Základní API

I "tab bar" je samozřejmě možné sestavit přímo v Interface Builderu. My si opět pro lepší pochopení nejprve ukážeme služby, potřebné pro programové sestavení "tabů" v kódu.

Na to, jak bohaté služby třída nabízí, je její základní API až překvapivě jednoduché. Nepotřebujeme speciální inicializátor (můžeme tedy použít prostě standardní init; jelikož se bavíme o programovém nastavení, nepotřebujeme žádný NIB, a argumenty případné zprávy initWithNibName:bundle: by stejně byly nil).

Jediné, co potřebujeme, je seznam řídicích objektů rámců, jež mají být uloženy v jednotlivých "tabech" – a ten se jednoduše uloží jako pole do atributu viewControllers. Pokud bychom tedy chtěli např. sestavit aplikaci, jejíž základní GUI je založeno na "tab baru" přepínajícím mezi řídicími objekty tříd A, B a C, mohlo by to vypadat zhruba takto:

#import "A.h" // první vnořený řídicí objekt
#import "B.h" // druhý vnořený řídicí objekt
#import "C.h" // třetí vnořený řídicí objekt

@implementation AppDelegate
@synthesize window;
@synthesize a,b,c; // všechny tři připraveny v XIBu
-(BOOL)application:(UIApplication*)app
  didFinishLaunchingWithOptions:(NSDictionary*)options {
  UITabBarController *tbc=[[UITabBarController alloc] init];
  tbc.viewControllers=[NSArray arrayWithObjects:a,b,c,nil];
  [self.window addSubview:tbc.view];
  [self.window makeKeyAndVisible];
  return YES;
}

To je vlastně vše – aplikace bude hned fungovat korektně, rámce, řízené objekty A, B a C bude možné vzájemně přepínat. Pokud řídicí objekty těchto rámců obsahují atributy title, budou tyto titulky v tabech korektně zobrazeny.

Ovšem... v tabech nebudou žádné ikony, a bez těch se samozřejmě neobejdeme. Pro nastavení požadovaných ikon nenabízí přímo vlastní API třída UITabBarController: ikony totiž (stejně jako některé další atributy, s nimiž se seznámíme později) se nastavují prostřednictvím pomocného objektu třídy UITabBarItem. Ten je s každým řídicím objektem rámce spojen prostřednictvím jeho atributu tabBarItem, podobně, jako tomu bylo u navigátoru s atributem navigationItem:

@interface UIViewController (UITabBarControllerItem)
@property(nonatomic,retain) UITabBarItem *tabBarItem;
...
@end

Mezi atributy tohoto pomocného objektu – tedy třídy UITabBarItem – pak patří také atribut image:

@property(nonatomic,retain) UIImage *image;

jehož nastavení právě určí ikonu pro daný "tab".

Za normálních okolností svou vlastní ikonu pro tab bar samozřejmě nastavuje každý řídicí objekt ve svém vlastním zdrojovém kódu – typicky ve vlastní metodě init... nebo awakeFromNib. My si zde ale ukážeme nastavení ikon "zvenku" – předpokládejme třeba, že řídicí objekty rámců A, B a C nebyly psány pro použití ve struktuře "tab bar". Pro zjednodušení kódu budeme také předpokládat, že odpovídající ikony jsou v projektu uloženy pod stejnými jmény, jako jsou jména tříd řídicích objektů – pro řídicí objekt A tedy bude existovat ikona "A.png" a podobně.

Pak stačí přidat do výše uvedeného kódu jediný příkaz

  ...
  tbc.viewControllers=[NSArray arrayWithObjects:a,b,c,nil];
  for (UIViewController *vc in tbc.viewControllers)
    vc.tabBarItem.image=
      [UIImage imageNamed:NSStringFromClass(vc.class)];
  [self.window addSubview:tbc.view];
  ...

a jsme hotovi.

Co když se taby nevejdou?

To je sice všechno pěkné, ale co když se pokusíme uložit do UITabBarControlleru řídicích objektů příliš mnoho, takže se do zápatí nevejdou?

Zkusme to – třeba takto (ačkoli v praxi se to z pochopitelných důvodů nedělává, nic nám nebrání mít v "tab baru" jeden jediný řídicí objekt několikrát):

  ...
  tbc.viewControllers=
    [NSArray arrayWithObjects:a,b,c,a,b,c,a,b,c,nil];
  ...

Uvidíme, že třída UITabBarController opravdu automaticky zajistí velmi bohaté standardní aplikační služby, o jejichž implementaci se vůbec nemusíme starat:

• prvé čtyři ikony se zobrazí a fungují normálně;

• na místě páté ikony se automaticky objeví standardní "trojtečka" s titulkem "Více";

• pokud ji použijeme, objeví se tabulka, jež obsahuje ikony a titulky všech řídicích objektů, jež se nevešly do "zápatí" (v našem případě jich zde tedy bude pět);

• klepnutím na kterýkoli z řádků této tabulky můžeme odpovídající řídicí objekt aktivovat; jeho rámec se zobrazí, ale standardně navíc dostane navigační záhlaví, umožňující návrat k tabulce;

• kromě toho je v záhlaví tabulky tlačítko "Edit"; pokud je použijeme, zobrazí se standardní konfigurační stránka, v níž můžeme změnit řídicí objekty, jež jsou uloženy v prvých čtyřech pozicích "tab baru".

To vše dostáváme zcela "zadarmo", aniž bychom pro to museli napsat jediný řádek kódu.

Ovšem... o jednu věc se postarat sami musíme: musíme zařídit, aby po ukončení aplikace a jejím novém spuštění byly v prvých čtyřech pozicích "tab baru" právě ty řídicí objekty, jež si tam naposledy uživatel umístil (a ne opět "a", "b", "c" a "d"). Jak? To si už – spolu s dalšími možnostmi a službami – ukážeme příště.