Я сделал все три, но с Objective C в качестве вызывающего языка вместо ruby.
AppleScript. Вы можете писать и вызывать AppleScript из ruby, используя osascript. AppleScript имеет отличную поддержку с точки зрения интерактивной разработки с использованием AppleScript Editor. Это очень хорошо работает. Но ... звонить через osascript обременительно, и вы вызываете дополнительный процесс каждый раз, когда разговариваете с iTunes. Вам также необходимо проанализировать вывод osascript - не очень важно, но определенно уводит вас от того, что вы действительно пытаетесь сделать.
Мост сценариев. Остается Scripting Bridge и appscript. Преимущество Scripting Bridge в том, что он является официальным кодом, поддерживаемым Apple. У Scripting Bridge есть свои недостатки, но он определенно работает, и поддержка инструментов хороша. Однако я не знаю, как бы вы интегрировали это с Ruby - кто-то другой может захотеть прокомментировать это.
приложение. У Appscript есть хорошая документация и хорошая репутация как превосходное связующее решение. Мэтт Нойберг явно перенес сценарий приложений на github (https://github.com/mattneub/appscript). с целью использования рубиновой части этого проекта. Другой форк (https://github.com/abarnert/appscript/network) добавляет дополнительные исправления, и с этого я бы начал. Я сам (https://github.com/poulsbo/appscript) довел Objective-C до date (примерно Xcode 6 beta 5), но я не касался рубиновой стороны.
Мост сценариев и сценарии приложений. Одно различие, которое я заметил между appscript и Scripting Bridge, с точки зрения пользователя, заключается в том, что appscript является более явным (хорошо), но также более подробным (плохо). Вот пример (псевдо-Obj C) получения свойства name объекта; вы явно делаете get и send:
id result = [[[appscriptObject name] get] send];
В то время как в Scripting Bridge есть неявная ленивая оценка, поэтому это больше похоже на:
id result = [sbObject name];
Также существует другая обработка информации о типе в сгенерированных заголовках. Я считаю, что Scripting Bridge лучше сохраняет информацию о типах.
Appscript лучше справляется с обработкой ошибок, например. сообщая вам, когда что-то недоступно. С помощью Scripting Bridge вы, кажется, получаете объект независимо, и после его использования вам нужно будет запросить его позже, чтобы узнать, что было за lastError. Я считаю эту схему кодирования некрасивой.
Взгляд назад? Как вы отметили, проблема в том, что сценарий приложений, вероятно, лучше всего рассматривать как «обратную технологию». Если вы его примете, вы рассчитываете поддерживать / исправлять любые проблемы в appscript самостоятельно или полагаться на исправления от других. Хотя кажется, что сегодня он работает хорошо (OS X 10.9), в будущем вы можете ожидать, что он сломается, или потребуется дальнейшее обслуживание, чтобы оно продолжало работать. С другой стороны, поскольку у вас есть исходный код, вы можете исправить проблемы самостоятельно. Ошибка в Scripting Bridge будет вне ваших рук.
Если вы хотите перевернуть это и смотреть вперед, возможно, вы захотите проверить, что Apple делает для Yosemite с JavaScript в качестве нового языка OSA. Однако это уходит от вашего первоначального вопроса, который касается рубина и iTunes.
Итог. Здесь есть разные компромиссы.
AppleScript. Будьте осторожны.
Мост сценариев. Хороший средний план? Но не знаю, как использовать из рубина.
приложение. Для энтузиастов / любителей.
JavaScript. Для раннего последователя.
person
Poulsbo
schedule
13.08.2014
