Což takhle trochu kakaa?

V tomto textu se postupně naučíme programovat v prostředí Cocoa. Dnes prostředí Cocoa patří firmě Apple; vzniklo však v rámci firmy NeXT a jejího operačního systému NeXTStep. Právě luxus a flexibilita tohoto vývojového prostředí byly patrně rozhodujícím faktorem, který Apple před třemi roky přiměl za bezmála půl miliardy dolarů firmu NeXT koupit.

Jestliže Cocoa patří Apple, je zřejmé, že jeho přirozeným životním prostředím jsou počítače Macintosh. Ani ostatní platformy však nepřicházejí úplně zkrátka: pro uživatele Linuxu a ostatních prostředí je nadějí projekt GNUStep, jehož cílem je uvolnit kompletní prostředí odpovídající "kakau" v rámci GNU licence. Konečně, pořád existuje naděje, že firma Apple se rozhodne využít bezproblémovou portabilitu prostředí, a bude nabízet svůj Mac OS X i pro jiné platformy: kód pro počítače Sun SPARC, Hewlett-Packard PA-RISC a IBM PC kompatibilní má k dispozici, stačilo by jej trochu oprášit...

Copak je to za novinky...

Je vhodné si uvědomit, že ačkoli technologicky je patrně Cocoa nejmodernější z dnes užívaných vývojových prostředí, novinkou v pravém smyslu slova není: vzniklo totiž jako vývojové prostředí NeXTStepu před patnácti lety. To je jeho nesmírná výhoda, protože díky tomu již jsou jeho dětské chyby dávno vychytány; navíc existuje po celém světě široká základna programátorů, kteří již s Cocoa — přesně řečeno s něčím velmi, velmi podobným — mají rozsáhlé zkušenosti.

Tehdy ovšem nikdo o kakau ještě nemluvil: vývojové prostředí NeXTStepu se nazývalo OpenStep. Firma Apple jej nejprve z nepříliš jasných důvodů přejmenovala na "Yellow Box", a teprve poměrně nedávno mu přidělila jméno Cocoa: je v tom vidět další hříčka na téma Java, a navíc Cocoa hezky aliteruje s alternativními prostředími, které Apple nabízí pro zachování kompatibility se starými versemi Mac OS, a jež se jmenují Classic a Carbon.

Co nenajdete ve výloze, hledejte uvnitř!

Každé vývojové prostředí se skládá v zásadě z knihoven služeb, jež mohou aplikace, které v něm vytváříme, využívat, a ze skupiny prostředků, jež nám v tom pomáhají: překladače programovacích jazyků, editory zdrojových textů, debuggery, generátory obrazovek a podobně. V tomto odstavci si zběžně ukážeme, jak na tom v tomto směru je Cocoa.

Kolik řečí znáš...

• Objective C je základním jazykem, ve kterém je celý systém vytvořen. Objective C je standardní jazyk C s doplněnou podporou objektů na podobných principech, na jakých je založen SmallTalk; díky tomu nabízí nesrovnatelně vyšší programátorský luxus pro práci s objekty, než C++ nebo dokonce i Java. S Objective C se v tomto seriálu seznámíme blíž, a budeme jej používat pro většinu příkladů.
• Alternativním jazykem je vedle Objective C také Java. Pro práci s objekty nenabízí tak pohodlné služby jako Objective C, a vinou částečné interpretace je také pomalejší. Na druhou stranu však má nezastupitelnou roli tam, kde požadujeme plnou přenositelnost: v Javě je možné psát kód distribuované aplikace, který poběží v rámci WWW browseru klienta na libovolné platformě!
• Standardní jazyk C je v prostředí Cocoa také plně podporován. Jeho využití je zčásti omezeno tím, že C nepodporuje práci s objekty, takže z něj nejsou přímo přístupné objektové knihovny; máme-li však hotový kód v C, který chceme do prostředí Cocoa přenést, není v tom žádný problém.
• Velmi podobně jako C podporuje Cocoa také jazyk C++. Plné využití objektových knihoven z C++ možné není (v kontrastu k rozšířenému omylu je nutné si uvědomit, že C++ není plnohodnotný objektový jazyk, ať si pan Virius klidně tvrdí opak), máme však k dispozici jeho překladač a můžeme jej využít pro přenos libovolného kódu, napsaného již dříve v C++, do prostředí Cocoa.

Za zmínku stojí samozřejmost, jež v jiných prostředích zdaleka není samozřejmá: v Cocoa můžeme bez nejmenších problémů v rámci jediné aplikace jazyky libovolně míchat; jediné omezení je, že více různých jazyků nesmíme používat v jednom zdrojovém souboru. Není však naprosto žádný problém, aby třeba každý zdrojový soubor v jediném projektu byl napsán v jiném jazyce! Cocoa navíc obsahuje promyšlenou sadu služeb, jež umožňuje plnou vzájemnou kompatibilitu mezi objekty Objective C a Javy.

Knihovny služeb

Mezi rysy, jež dávají prostředí Cocoa jeho výjimečné postavení, bezpochyby patří i nesmírně luxusní knihovny služeb. S těmi se v průběhu našeho seriálu samozřejmě seznámíme podrobněji; zde si prozatím jen v rychlosti projdeme čtyři základní skupiny knihoven, jež Cocoa nabízí — jejich přehled vidíme na následujícím obrázku:

• Základem všeho je Foundation Kit. V něm jsou soustředěny základní služby, jež potřebujeme při tvorbě libovolné aplikace, bez ohledu na konkrétní prostředí, ve kterém poběží: kontejnerové objekty, nesmírně luxusní práce s textovými řetězci s plnou podporou UNICODE i řady osmibitových kódování, přístup k souborům, komunikace mezi procesy, a mnoho a mnoho dalších služeb.
• Enteprise Objects Framework, zkráceně EOF, doplňuje a rozšiřuje služby Foundation Kitu o přístup k databázím. EOF je navržen natolik flexibilně, že databáze mohou být vlastně libovolné, včetně prostých DBF nebo dokonce textových souborů; nejčastěji však spolupracuje s výkonnými SQL servery.
• Připravujeme-li aplikaci, jež bude pro interakci s uživatelem využívat standardní služby operačního systému (tj. myš, klávesnici, obrazovková okna a podobně), sáhneme po knihovně AppKit. V ní jsou třídy representující všechny standardní prvky uživatelského rozhraní, od oken nebo menu až po poslední tlačítko; navíc je zde kompletní podpora interakce s uživatelem, a plně přenositelné grafické služby, nezávislé na konkrétním Window Serveru.
• Knihovna WebObjects naopak poslouží v případě, kdy by nám služby AppKitu byly málo platné, protože aplikace má s uživateli komunikovat prostřednictvím internetu: namísto klávesnice a obrazovky se tak vlastně uživatelským rozhraním aplikace stává WWW browser, běžící na jakékoli platformě. Podporuje-li takový browser Javu, může taková aplikace běžet zčásti i u klienta; jinak výkonný kód běží jen na serveru a s klientem komunikuje prostřednictvím protokolu HTTP.

Samozřejmě, že Cocoa obsahuje řadu dalších knihoven; ty jsou však relativně podružné. My se v tomto seriálu soustředíme na základní služby čtyř výše popsaných knihoven Foundation a AppKit.

Za zmínku stojí ještě to, jak jsou knihovny v prostředí Cocoa representovány: na rozdíl od většiny ostatních systémů se zde nejedná o "nějakou DLLku", ale o propracovaný mechanismus, nazývaný framework. Součástí frameworku jsou kromě vlastních knihoven také podpůrné soubory, hlavičkové soubory pro překladač, dokumentace a podobně; tak je všechno na jednom místě a nemůže dojít ke zmatkům. Frameworky navíc využívají propracovaný systém versí, a v případě zásadních změn je možné v jediném frameworku uložit i starší verse knihoven, aby starší aplikace nadále bez problémů pracovaly. Klasický windowsovský zmatek "tahle DLL je moc stará, a támhleta zase moc nová, takže aplikace nefunguje" tak nepřipadá v úvahu.

Aplikace a pomocné prostředky

Samotné skvělé knihovny a překladače nestačí: je třeba mít k dispozici přinejmenším dobrý editor zdrojového kódu, a debugger. Nadto právě Cocoa ukazuje, jak obrovským usnadněním práce může být visuální programování, když se udělá pořádně: v dlouhodobém průměru trvá tvorba stejné aplikace v prostředí Cocoa zhruba desetinu času oproti jiným prostředím! To je právě díky systému, který se dodnes — a dodnes marně! — snaží okoukat systémy typu Delphi nebo Visual C++.

• O integraci celého vývojového řetezu se stará aplikace ProjectBuilder: sám obsahuje editor zdrojového kódu a umí spolupracovat s debuggerem, a podle potřeby sám spouští ostatní aplikace.
• Pracujeme-li s databázemi, potřebuje EOF znát podrobnou strukturu dat a jejich vzájemných relací. K tomu slouží EOModeler, který je vidět na další ilustraci. Strukturu dat v něm specifikujeme pomocí E-R modelů; EOF pak již sám na základě modelu vytváří a udržuje objekty, representující data v databázi, a jejich vzájemné vazby.
• Skutečnou magii, umožněnou plnohodnotným objektovým systémem, nabízí InterfaceBuilder — aplikace pro interaktivní tvorbu a údržbu objektových sítí. Jak jméno naznačuje, nejčastěji se takové sítě skládají z objektů uživatelského rozhraní; to ilustruje také příklad na dalším obrázku:
  
  natažením černé čáry mezi posuvníkem a textovým polem jsme právě "naprogramovali", že hodnota zobrazená v poli bude vždy odpovídat pozici posuvníku. InterfaceBuilder však není v žádném případě omezen jen na práci s grafickými objekty: příští obrázek ukazuje jiné propojení, jímž jsme určili, že databázový objekt "Studio" bude representovat položku studia, odpovídající zvolenému filmu v databázovém objektu "Movie":
  
  
• Podobná kouzla pro internetové aplikace dokáže WebObjectsBuilder: obrázek
  
  ukazuje, jak jsme navázali tlačítko ve vytvářené WWW stránce na metodu performTest; vedle je navíc vidět již dříve vytvořená vazba mezi proměnnou userName a textovým polem. Jakmile pak někdo otevře URL takovéto aplikace ve svém WWW browseru, zobrazí se stránka, vypadající nějak jako příští ilustrace — na místě "OCSoftware" samozřejmě bude libovolný text, který byl zrovna uložen v proměnné userName. Jestliže pak uživatel browseru klepne na tlačítko, spustí se v aplikaci metoda performTest...
  

Ovšemže i podpůrných prostředků je v systému Cocoa mnohem víc: máme zde k dispozici např. luxusní profiler pro vyhledávání "bottlenecků" v pomalých aplikacích, nebo třeba aplikace pro vyhledávání a odstraňování alokované nevyužité paměti. Podobně jako u knihoven, v našem seriálu se soustředíme jen na ty základní.

Copyright © Chip, O. Čada 2000-2003