Nastal čas na kakao - Více o XCode: inspektory - MujMAC.cz - Apple, Mac OS X, Apple iPod

29. září 2004, 00.00 | Chystáme se připravit naši druhou aplikaci, v níž bychom využili většinu toho, co jsme se učili v minulých pokračováních našeho seriálu. Nejdříve si však musíme říci alespoň nejzákladnější věci o vývojovém prostředí firmy Apple, o XCode.

Chystáme se připravit naši druhou aplikaci, v níž bychom využili většinu toho, co jsme se učili v minulých pokračováních našeho seriálu. Nejdříve si však musíme říci alespoň nejzákladnější věci o vývojovém prostředí firmy Apple, o XCode.

S jeho úplnými základy jsme se seznámili hned na začátku, když jsme připravovali náš první program; minule jsme si vysvětlili hlavní prvky okna projektu. Dnes si ukážeme zbývající velmi důležitý prvek uživatelského rozhraní XCode, jeho inspektory.

Obecně, inspektory nabízejí dodatečné informace o objektu, vybraném v hlavním okně, a často je umožňují i podle potřeby měnit. Stejně jako jsme tomu zvyklí ve Finderu, nabízí i XCode dvě podoby inspektoru. Prvá se nazývá "Info" (Project / Get Info, je i v kontextové nabídce); ta otevře inspektor pevně vázaný k právě označenému objektu – takových inspektorů pak můžeme mít otevřených libovolně mnoho najednou, každý pro jiný objekt. Druhá, "Project / Show Inspector", otevře obecný inspektor, v němž vždy vidíme informace o právě označeném objektu: toto okno je samozřejmě jen jediné, a jeho obsah se změní kdykoli v hlavním okně zvolíme jiný objekt.

Informace o projektu

Vyžádáme-li si inspektor pro prvou skupinu, označenou jménem projektu, vidíme inspektor projektu. Ten má tři nebo čtyři panely: "General", který vidíme na následujícím obrázku, "Code Sense" a "Styles"; čtvrtým panelem může být "SCM", pokud jej aktivujeme (v témže inspektoru, viz obrázek dole, "Enable SCM"):

Za normálních okolností můžeme chtít pouze měnit jméno projektu v panelu "General", případně – pokud se indexování "zblázní", což se bohužel občas stává – si tlačítkem "Rebuild Index" v panelu "Code Sense" vyžádat nové oindexování.

Panel "Styles" nabízí přebohaté možnosti natavení způsobu, jakým se projekt (přesněji řečeno, jeho targety) bude generovat; to však je "vyšší dívčí", na niž prozatím, stejně jako na SCM, zapomeneme: touto magií se budeme v našem seriálu zabývat mnohem později.

Informace o souborech

Inspektory věnované obecným skupinám nejsou podstatné; stojí však za to se blíže podívat na inspektory, věnované jednotlivým souborům:

Poměrně důležitá je cesta ("Path" a "Path Type"): XCode totiž dokáže udržovat v rámci projektu jakékoli soubory, i takové, jež leží zcela mimo projekt; ty pak mají absolutní cestu, a pokud projekt archivujeme jako složku, přijdeme o ně ☺ Je tedy třeba si dát na užívání vhodné cesty pozor (XCode se při vkládání nových souborů do projektu ptá, jaký typ cesty pro ně má použít a má-li je případně zkopírovat do složky projektu).

Právě "File Type" určuje, jakým způsobem se ten který soubor zpracuje: soubory "sourcecode..." se přeloží (a podle toho, zda jde o "sourcecode.c.objc" nebo třeba o "sourcecode.java", se zvolí vhodný překladač).

Zbývající ovladače nejsou tak důležité: umožňují specifikovat kódování použité pro soubor (aby jej editor, který je součástí XCode, zobrazil správně), a pomocí tlačítek dole lze řídit lokalizované varianty nejrůznějších datových souborů: k tomu se také vrátíme mnohem později, až se budeme učit, jak psát lokalizovatelné aplikace.

Druhý panel "Build" mají jen soubory, jež se překládají; v něm lze nastavit přepínače pro překladač, jež se mají užít specificky právě jen pro tento soubor.

Informace o targetech

Asi vůbec nejdůležitější z inspektorů je inspektor targetů, v němž určujeme základní informace o celé výsledné aplikaci. I ten má několik panelů, z nichž je nejdůležitější poslední, "Properties" – XCode automaticky otevře tento inspektor pro target, pokud na něj poklepeme.

První tři panely využijeme poměrně málokdy: "General" umožňuje target přejmenovat a také jeho prostřednictvím můžeme určovat vzájemné závislosti mezi targety, máme-li jich v projektu více (např. "nejprve je nutno vygenerovat knihovnu, protože na ní závisí aplikace"). Panel "Build" obsahuje obdobné informace, jako panel "Styles" projektu, a oba spolu umožňují pokročilým programátorům přesně specifikovat jak má generování probíhat. S tím souvisí i panel "Rules", který obsahuje vazby mezi typy překládaných souborů a překladači.

Zatímco úpravy obsahu tří prvých panelů nejsou zapotřebí – snad vyjma závislostí mezi targety u složitějších projektů – takřka nikdy, ve čtvrtém panelu – již zmíněných "Properties" – musíme upravit alespoň jednu z položek pro každý nový projekt (který vytváří aplikaci, vyjma velmi triviálních testovacích jež neopustí náš počítač):

Jméno výsledného spustitelného souboru – "Executable" – měníme jen málokdy. Zato hned "Identifier" musíme pro každou aplikaci určit vlastní; konvence, již dodržují prakticky všichni programátoři, zní "jméno domény odzadu plus jméno aplikace": tak je zaručeno, že se nesejdou dvě různé aplikace s týmž identifikátorem. Identifikátor se krom jiného používá i pro jméno aplikačních předvoleb – pokud by dvě různé aplikace měly týž identifikátor, navzájem by jedna druhé předvolby ničila...

Na typ a creator se většinou ohlížet nemusíme; jde o pohrobka nepříliš šťastně navržených metadat starého systému Mac OS (9 a méně), jichž se bohužel Mac OS X dodnes nedokázal zbavit. Oba prostě ponecháme jak jsou – typ je (pro aplikace) 'APPL', a creator může klidně zůstat '????'. Snad jen pokud bychom chtěli užívat Carbonu, mohlo by stát za to nastavit vlastní creator; na úrovni Cocoa jej však daleko, daleko lépe nahradí právě identifikátor.

Ikona je naproti tomu poměrně důležitá: chceme-li, aby naše aplikace k něčemu vypadala, vytvoříme obrázek ve formátu ICNS (bohužel, Mac OS X pro tento účel nepodporuje standardní TIFF; součástí vývojářských aplikací však je i aplikace Icon Composer ve složce Utilities, jež formát ICNS dokáže generovat), vložíme jej do projektu (a postaráme se o to, aby byl součástí targetu), a jeho jméno zapíšeme do pole "Icon File".

Versi určíme podle potřeby. "Principal Class" ani "Main Nib File" zatím měnit nebudeme; časem se naučíme, k čemu to může být dobré.

V dolní části okna pak můžeme specifikovat typy dokumentů, s nimiž aplikace pracuje. Prozatím se soustředíme na jednoduché aplikace, jež dokumenty nemají; tabulka tedy zůstane prázdná.