Архітектура завантажуються Bundle-пакетів
Додаток Automator засноване на архітектурі завантажуються bundle-пакетів. Він завантажує завантажуються пакети викликає дії і виконує код, який міститься в послідовності визначається поточним робочим процесом, переводячи потоки даних від однієї дії до іншого.
Кожна дія упаковано як завантажується пакет або в разі AppleScript дії, засновані на потенційно завантажуються пакетах. Завантаження пакет містить ресурси різних видів і зазвичай двійкового коду, але він не здатний виконувати цей код сам по собі. Внутрішня структура Cocoa bundle-пакетів представлена в формі, яка "розуміє" NSBundle об'єкт. Використання NSBundle об'єкта, додатком або бібліотекою може завантажити ресурси і код для завантаження під час виконання і інтегрувати їх з тим кодом, який воно вже містить. Офлайн bundle-пакети по суті мають архітектуру плагінів.
Коли він запускається, Automator негайно сканує встановлені дії пакета і витягує з інформаційного списку властивостей кожного пакета (Info.plist) інформацію, необхідну для його відображення і підготовки його до використання. Automator дії (у вигляді для завантаження) зберігаються в стандартних місцях файлової системою:
/ System / Library / Automator - Надані Apple дії
/ Library / Automator - Інші дії для всіх користувачів
/ Library / Automator - Інші дії для поточного користувача
Automator також шукає дії, які зберігаються всередині bundle-пакетів будь-яких зареєстрованих додатків.
Коли він запускається, Automator також завантажує будь-Mach-O код, який він знаходить в пакеті-дії, який в даному випадку є Objective-C-дією тільки дозволених зовнішніх посилань в цьому процесі. Якщо дія заснована на Objective-C, екземпляр AMBundleAction (або підклас цього класу) розархівуйте з nib. Проте, якщо дія повністю побудовано на AppleScript або сценарії оболонки, Automator натомість зберігає посилання на пакет, так як немає Mach-O коду для завантаження. Коли користувач перетягує така дія в область робочого процесу Automator в перший раз, програма завантажує дію, його nib файл розпаковується, і відображає вид дії.
Новий робочий процес
Коли користувач створює новий робочий процес шляхом перетягування одного або декількох дій в макет робочого процесу, Automator робить кілька речей:
Якщо дія заснована на AppleScript він створює екземпляр AMAppleScriptAction як власник пакета, і також завантажує сценарій так AppleScript Studio може виконати деяку ініціалізацію. Якщо дія заснована на сценарії оболонки, Automator, замість цього, створює екземпляр AMShellScriptAction.
Він отримує уявлення вмісту, що міститься в пакеті дії і відображає його у вигляді дії в області робочого процесу, встановлюючи значення за замовчуванням для текстових полів і елементів управління, як це визначено в AMDefaultParameters властивості дії.
Витяг з архіву робочого процесу
При збереженні робочий процесу або копіюванні його через буфер обміну, робочий процес і всі його дії архівуються. Automator викликає метод writeToDictionary: кожного з дій в робочому процесі, які направляються в змінюваний словник з параметрами дії та іншою інформацією. Дія може вибрати модифікацію вмісту словника перед поверненням з writeToDictionary. Потім об'єднані словники кожної дії робочого процесу кодуються і архівуються.
Після того як всі дії в робочих процесах були переініціалізіровани з архіву, робочий процес готовий до використання. Користувачі можуть вибирати параметри в діях і запускати робочий процес.
Програмні наслідки для завантаження
Доступ до Bundle-пакету
Одне з питань, з пакетами виникає з відмінностей між основними пакетами таких додатків, як Automator і пакетами, які завантажуються додатками. Якщо ви запопросіте головний пакет в вашому коді дії, наприклад:
NSBundle * theBundle = [NSBundle mainBundle];
ви отримаєте головний пакет додатка Automator, а не пакет дій, що викликає mainBundle. Для пакета дії, необхідно відправити повідомлення на пакет об'єкта дії (які, як правило, сам реалізує код дії):
NSBundle * theBundle = [self bundle];
Метод bundle оголошений в AMBundleAction класі, всі дії якого успадковуються з класу, прямо або побічно
Розархівація nib файлу
Cocoa програми часто реалізують метод awakeFromNib (його колега в AppleScript обробник команди awake from nib). Метод awakeFromNib викликається, коли всі об'єкти nib файлу програми були розархівовані. Це дає програмі змогу виконати ініціалізацію, яка вимагає присутності всіх витягнутих з архіву об'єктів.
Однак метод awakeFromNib викликається, коли Automator буде запущений. В цей час Automator читає будь-який двійковий код дії в стандартних місцях Automator і безпосередньо розархівуйте об'єкти в nib файлах, якими він безпосередньо володіє. Проте, ці об'єкти не включають в себе об'єкти в nib файлах дій. nib файл дій не завантажений і його об'єкти не розархівовані поки користувачі не перетащат дію в робочому процесі. Якщо ви хочете виконати ініціалізацію, яка вимагає присутності всіх об'єктів і зв'язків в nib файлі дії, реалізуйте метод opened замість awakeFromNib.
простір імен
Objective-C клас визначає простір імен для методів і змінних екземпляра, які він оголошує. У зв'язку з цим однойменні методи і змінні в інших класах не викликають конфлікти в процесі. Однак ім'я самого класу існує в просторі імен, що займається всіма класами, завантажених процесом. Крім того, всі глобальні символи (наприклад, функції і типи даних) також знаходяться в одному і тому ж просторі імен в процесі.
Для Automator, з його архітектурою для завантаження (або плагінів), потенційна ймовірність конфліктів імен, а, отже ймовірність -виняток під час виконання є значною. Automator потенційно може завантажити сотні дій з різних джерел і, наприклад, якщо два класи дії мають однакові імена або оголошують строкову константу з тим же ім'ям, є потенціал для конфлікту імен, коли ці дії, завантажуються Automator.
Щоб уникнути конфліктів імен, рекомендується призначати префікси для всіх класів і глобальних типів, які є відмінними наскільки, наскільки це можливо. Наприклад, якщо назва вашої компанії Acme, Ви могли б назвати клас AC_FilterImages.
Передача потокового архітектура
Для підвищення стабільності і виконання дають AppleScript дії, засновані на доступі до таких ресурсів, як Standard Additions, Automator має потокову архітектуру, яка ставить різні види програмної діяльності в окремі потоки. Automator запускає робочий процес на вторинному потоці (тобто, потік, відмінний від основного потоку). Але, він запускає кожна дія в різному потоці залежно від того, заснована дія на AppleScript або Objective-C:
- Якщо дія заснована на AppleScript, воно виконується в головному потоці. Реалізація дозволяє користувачам скасувати виконання дії на цьому потоці, натиснувши кнопку зупинки.
- Якщо дія заснована на Objective-C або сценарії оболонки, вона виконується на вторинному потоці.
Ця потоковая архітектура накладає обмеження на обидва способи написання дій, як на основі AppleScript, так і Objective-C. Якщо дія на основі AppleScript використовує команду do shell script. призначений для користувача інтерфейс не відповідає, поки сценарій не завершиться; єдиний спосіб, яким користувачі можуть скасувати виконання, це натиснути Command-period. Якщо Objective-C дії відображають вікна, вони повинні зробити це в головному потоці використовуючи такий метод, як performSelectorOnMainThread: withObject: waitUntilDone:.
класи Automator
Automator як технологія включає в себе не тільки додатки і його дії, але і Automator бібліотеку (Automator.framework). Бібліотека реалізує більшу частину загального поведінки дій, а також забезпечує загальний інтерфейс, який визначається чотирма класами: AMAction, AMBundleAction, AMAppleScriptAction і AMShellScriptAction. Ці класи є ієрархічно пов'язаними (з точки зору успадкування), як показано на малюнку нижче.
AMBundleAction клас безпосередньо успадковується від AMAction і забезпечує конкретну його реалізацію. AMBundleAction визначає інтерфейс і загальна поведінка дій, які є завантажуються пакетами. AMBundleAction об'єкти мають три основні властивості:
Bundle-пакетним дій, розробленим з уявленнями видів, доступні ресурси пакета і доступні параметри для дії. Вони розширюють завантажуються пакети дій так, щоб скрипти AppleScript або скрипти могли управляти логікою дії, замість Objective-C коду (хоча AppleScript, Objective-C, і навіть скрипт оболонки код може бути змішаний в реалізації дії). Єдиним виходом AMAppleScriptAction є OSAScript об'єкт, який представляє сценарій, за замовчуванням цей вихід встановлений на об'єкт, що представляє main.applescript.
Ви можете створити свої власні підкласи на останніх двох рівнях ієрархії класів Automator, тобто на AMBundleAction вниз, щоб отримати об'єкти з характеристиками і можливостями, як вам потрібно. Якщо ви хочете створити завантажується bundle-пакет дії, поведінку якого визначається мовою сценаріїв відмінним від AppleScript, Perl, Python, сценарій оболонки, ви б створили підклас AMBundleAction.
Концептуально, два основних зовнішніх факторів для дії є вхідними об'єктами, переданими йому на розгляд від попереднього дії (якщо такі є) і параметри, зазначені користувачами за допомогою елементів управління і текстових полів виду дії. Екземпляру AMBundleAction доступний вхідний об'єкт в його реалізації runWithInput: fromAction: error: і отримує параметри безпосередньо з призначеного для користувача інтерфейсу через механізм Cocoa bindings. Для дій на основі AppleScript (представлених наприклад AMAppleScriptAction), вхідні параметри об'єкта ще більш явні. Вони зустрічаються у вигляді переданих значень в обробник on run. як показано на малюнку нижче:
