Mac OS X 10.4 Tiger - Automator a programátor - MujMAC.cz - Apple, Mac OS X, Apple iPod

26. dubna 2005, 00.00 | V minulém článku jsme si ukázali základy nové technologie Automator, jež se objeví za pár dní v Mac OS X 10.4 – Tiger; vysvětlili jsme si principy, na nichž je založena, a ukázali jsme si její grafické uživatelské rozhraní, jak jej nabízí aplikace Automator.

V minulém článku jsme si ukázali základy nové technologie Automator, jež se objeví za pár dní v Mac OS X 10.4 – Tiger; vysvětlili jsme si principy, na nichž je založena a ukázali jsme si její grafické uživatelské rozhraní, jak jej nabízí aplikace Automator.

Jakkoli je dnešní díl věnován především programátorům, jimž ukáže základní principy, podle nichž mohou vytvářet pro Automator nové akce, vyplatí se jeho přečtení i běžným uživatelům: těm dá podrobnější popis struktury "akce" lepší představu o tom, jak Automator přesně funguje, co dokáže, a co nedokáže.

Základy

Pro začátek ještě stručně zopakujme ta nejzákladnější fakta, neboť – jak ukázala diskuse pod minulým článkem – řada uživatelů očekává od Automatoru služby, jež nenabízí, neboť si jej pletou s něčím docela jiným. Automator není systém pro řízení aplikací (ačkoli řada jeho akcí řízení aplikací nabízí), stejně jako Automator není třeba systém pro zpracování obrázků (ačkoli řada jeho akcí nad soubory s grafikou pracuje). Automator je prostě a jednoduše systém pro sestavování pracovních postupů z jednotlivých akcí.

• součástí systému je databáze akcí; každá akce nabízí nějakou elementární činnost typu "zmenšit obrázek", "odeslat e-mail" či "archivovat soubory". Konkrétní akce mohou být založeny na AppleScriptu a řídit aplikace; mohou být založeny na Objective C a využívat obecné systémové služby; mohou být založeny (prostřednictvím C) na shellových scriptech či na čemkoli jiném;
• akce mají jasně definované vstupní a výstupní body prostřednictvím typů dat, nad nimiž dokáží pracovat, a jež naopak mohou vytvářet;
• uživatel může právě na základě shodných datových typů sestavovat akce dohromady do pracovních postupů ("workflows");
• pracovní postup lze uložit do souboru a kdykoli znovu přehrát. Tiger dokonce umožňuje pro větší pohodlí a flexibilitu vytvářet "automatorové aplikace" – pracovní postupy, jež vypadají jako samostatné aplikace a lze je tak používat – a "automatorové pluginy", jež doplní služby, definované prostřednictvím pracovních postupů, do jiných aplikací (vyvoláváme-li tak třeba nějaký pracovní postup třeba z aplikace iCal, můžeme jej uložit jako její plugin, a de facto tak rozšíříme její služby).

Dalo by se tedy říci, že akce Automatoru jsou vzdálenou grafickou obdobou příkazů unixového shellu s jejich podporou standardního vstupu a výstupu; pracovní postup pak lze velmi přibližně přirovnat k řadě těchto příkazů spojených prostřednictvím pipe.

Rozhodně nejde v žádném případě o obdobu "nahrávání" akcí provedených v GUI, jež bývalo kdysi (v praxi nepříliš dobře použitelnou) službou Mac OS. Také má Automator jen málo společného s AppleScriptem nebo s technologií AppleEvents: jistě, některé konkrétní akce mohou být napsány v AppleScriptu nebo mohou (prostřednictvím odpovídajícího API) přímo využívat AppleEvents, ale Automator sám s tím "nemá nic společného". Přesně stejně jiné akce mohou provádět zpracování textu a přesto neřekneme, že Automator je wordprocesor; jak uvidíme na konci tohoto článku, existuje i skupina standardních akcí, usnadňující práci programátorům – přesto však Automator rozhodně není programátorský tool.

Co je to "akce"?

Jak jsme si slíbili minule, dnes se budeme Automatoru věnovat především z pohledu programátora: ten může vytvářet akce, jež se zařadí do systémové databáze, a kdokoli je pak může využívat ve svých pracovních postupech.

Jak už jsme si vlastně nepřímo řekli, "akce" je representována v zásadě trojicí "objektů" (nikoli ve smyslu objektového programování):

• popis typu vstupních dat, nad nimiž akce pracuje (případně informace, že akce žádná vstupní data nepotřebuje, neboť je sama vytváří);
• vlastní akce, tedy program zapsaný v některém z mnoha programovacích jazyků, jež Mac OS X podporuje – stejně dobře můžeme pro definování akce použít shellové skripty, AppleScript, jazyk Objective C s využitím plné síly vývojového prostředí Cocoa, nebo třeba plain C pro akce, využívající nízkoúrovňových systémových služeb. Akce také samozřejmě má vlastní uživatelské rozhraní, jež uživateli umožní nastavit její atributy.;
• popis typu výstupních dat, jež akce generuje.

Na základě těchto informací již může Automator akce vkládat do pracovních postupů a provádět je. Kromě toho je z techického hlediska méně podstatnou, ale v praxi velmi důležitou součástí akce její dokumentace, jež uživateli umožní snadno volit kterou akci do pracovního postupu zahrnout a jak ji použít.

Programátoři takové akce vytvářejí přímo ve vývojovém prostředí Xcode, jehož verse 2, standardně dodávaná jako součást Tigeru, obsahuje odpovídající podporu a standardní vzory odpovídajících projektů. Typy vstupních i výstupních dat (stejně jako dokumentace) jsou uloženy v souboru Info.plist, jenž obsahuje podrobné údaje o package, jenž jej obsahuje.

Program může být v zásadě zapsán v Objective C nebo v AppleScriptu. Objective C ovšem nabízí přístup ke všem službám systému; lze tedy jeho prostřednictvím využít i třeba schopností unixového shellu nebo jiných programů – včetně již hotových ostatních pracovních postupů Automatoru...

Základní princip je prostý: existuje smluvený vstupní bod, který Automator zavolá, pokud má být akce provedena. V Objective C kupříkladu vstupní bod vypadá zhruba takto:

-runWithInput:o fromAction:(AMAction*)action error:(NSDictionary**)error {
  // tato akce jen vrátí vstupní objekty v opačném pořadí
  // a v praxi samozřejmě nemá rozumný smysl :)
  NSEnumerator *en=[o reverseObjectEnumerator];
  NSMutableArray *ma=[NSMutableArray array];
  while ((o=[en nextObject])) [ma addObject:o];
  return ma;
}

Povšimněte si, že vstupní argument i návratová hodnota jsou typu id (to je v Objective C standardní typ, jenž se použije, není-li řečeno jinak) – to proto, že ačkoli naprostá většina akcí zpracovává pole objektů a pole objektů také vrací, není to nutnou podmínkou, a některé akce mohou přijímat i vracet objekty odlišné.

Pro uživatelské rozhraní slouží docela standardní NIB – objektová síť, definovaná pomocí aplikace InterfaceBuilder:

Je také samozřejmé, že pro vazbu mezi uživatelským rozhraním a daty lze využívat meta-programování na základě tzv. vazeb (bindings).

Akce pro programátory

Ačkoli lze předpokládat, že programátoři budou akce častěji psát nežli využívat, Automator standardně obsahuje dokonce i řadu akcí speciálně zaměřených na to, abychom mohli snadno a pohodlně automatizovat pracovní postupy, běžné při vytváření aplikací.

Sem patří třeba akce zajišťující "zbuildování" projektu, vygenerování instalačního balíku pro daný software či řízení verse projektu. K dispozici máme také služby vázané na systém správy versí zdrojového kódu CVS, služby související s databází SQL a další...