Adobe sdk что это
Разработчики программного обеспечения пользуются основными инструментами: SDK и API. По сути, как SDK, так и API позволяют улучшить функционал приложений, не прибегая к большим усилиям.
Что такое SDK?
Аббревиатура SDK расшифровывается как software development kit. SDK, или devkit, — это набор средств для разработки ПО под определенную платформу. Он содержит компоновочные блоки, средства отладки, а зачастую фреймворк или группу библиотек кода, например набор подпрограмм для определенной операционной системы.
В стандартном SDK могут присутствовать как некоторые, так и все компоненты из списка ниже:
- Компилятор: переводит с одного языка программирования на используемый вами.
- Примеры кода: демонстрируют примеры приложений или веб-страниц.
- Библиотеки кода (фреймворк): предоставляют фрагменты кода, часто используемые программистами.
- Инструменты для тестирования и аналитики: предоставляют аналитические данные о работе продукта в тестовой и эксплуатационной средах.
- Документация: содержит инструкции для разработчиков.
- Средства отладки: помогают разработчикам обнаруживать ошибки в коде, чтобы публикуемый код работал как задумано.
Как работает SDK
SDK предоставляет инструменты, которые способствуют ускорению и стандартизации разработки приложений.
- Приобретите, загрузите и установите набор SDK для своей платформы (например, предварительно подготовленные фрагменты сборки, примеры и инструкции).
- Откройте и используйте любые API исредства разработки, необходимые для создания нового приложения, начиная с интегрированной среды разработки (IDE). Это пространство, в котором работает программист и установлено средство отладки.
- При разработке используйте инструкции, документацию, примеры кода и инструменты тестирования, которые обеспечат вам и вашей команде хороший старт.
Примеры использования SDK
SDK — неотъемлемая часть разработки мобильных приложений. SDK имеют множество областей применения:
- SDK для определенных языков программирования, например JSON и Java Developer Kit (JDK) для JavaScript и Java соответственно, используются для разработки программ на этих языках оптимальным и стандартизированным путем.
- SDK для аналитики от Google и других компаний предоставляют данные о пользовательских действиях, поведении и путях их перемещения по сайту или приложению.
- SDK для монетизации от Google, Facebook и других компаний упрощают интеграцию рекламы с существующими приложениями с целью получения дохода.
Преимущества SDK
- Доступ к компонентам и инструкциям для разработки ПО: например, SDK для ритейла содержит все элементы, необходимые для приложений в этой отрасли (например, «Избранное», «Корзина», «Сохранить заказ», «Оформить заказ» и т. д.).
- Ускоренная и слаженная интеграция: SDK упрощают стандартные процессы и предоставляют доступ к необходимой информации.
- Сокращение цикла разработки, повышение эффективности развертывания и вывода продуктов на рынок: поскольку SDK созданы для информирования, предоставления необходимых инструментов и шаблонов, разработчики могут сфокусироваться на разработке своего продукта.
- Встроенная поддержка и экспертные знания: нет необходимости искать ответы или нанимать дополнительных экспертов в свою команду; SDK уже содержат код, написанный экспертами, и всю необходимую сопроводительную документацию.
- Контроль расходов: все перечисленное выше позволяет оставаться в рамках бюджета во время разработки и после развертывания.
Что такое API?
Аббревиатура API расшифровывается как application programming interface (интерфейс программирования приложений). API — и как отдельное решение, и в составе SDK — облегчает обмен данными между двумя платформами и позволяет сторонним разработчикам использовать функционал проприетарного ПО.
API можно рассматривать как соглашение между двумя сторонами. API не только обеспечивает возможность обмена данными, но и устанавливает его правила.
Поскольку некоторые API предоставляют интерфейс напрямую, термины API и «интерфейс» иногда взаимозаменяемы.
Чтобы внести ясность, стоит отметить, что API может состоять из двух компонентов:
- Технические спецификации и документация: информация об интеграции и эффективном использовании API.
- Интерфейс: доступ к нему осуществляется как напрямую, через ключевое слово (в случае веб-API), или косвенно, через отдельный интерфейс (в случае REST API).
Что представляет вызов API с технической точки зрения:
- Как пользователь приложения, которому необходимо выполнить задачу, вы инициируете задачу из своего приложения, создавая запрос.
- API совершает вызов к веб-серверу, передавая запрос. API знает, куда отправлять запрос, поскольку он передается в конечную точку API, обычно — URL сервера.
- Запрос выполняет стороннее приложение или база данных, предоставляющие такой сервис.
- API в картографии обычно используются для интеграции карты на веб-странице или в мобильном приложении.
- API платежных сервисов обычно используются компаниями, занимающимися e-commerce, для повышения гибкости процесса покупки, что приводит к расширению базы потенциальных клиентов.
- API метеорологических служб могут улучшить опыт пользователей спортивных приложений, поисковых систем и т. д.
- Объединение разнородных программных приложений для создания более сильного продукта
- Сокращение цикла разработки за счет автоматизации
- Снижение нагрузки на штатные ресурсы
- Повышение узнаваемости бренда и доверия к нему
- Максимально эффективное предоставление новых сервисов конечным пользователям
Нужно ли выбирать между SDK и API?
Нет, ведь как сказано выше, SDK зачастую имеет по меньшей мере один API. Они выполняют разные функции, но могут работать и помогать вместе.
Следует иметь в виду, что с использованием API и SDK связаны некоторые сложности. Одна из них заключается в потенциальных уязвимостях. Другая сложность, относящаяся к SDK, — частота обновлений. Поэтому важно, чтобы команды DevOps держали вопрос информационной безопасности в поле зрения, а также следили за своевременным обновлением компонентов.
Welcome to the 2021 release of the Acrobat SDK. The downloads are new and the documentation is rapidly evolving.
The Acrobat SDK provides tools that help you develop software that interacts with Acrobat technology. The SDK contains header files, type libraries, simple utilities, sample code, and documentation. These tools provide several methods for developing software that integrates with Acrobat products, including JavaScript, plugins, and interapplication communication.
This SDK release introduces support for Windows 64-bit. Details include:
You must upgrade 32-bit plugins to 64-bit for them to work with the 64-bit app.
The SDK provides 64-bit public headers to 3rd party plug-in developers so that they can successfully create or upgrade their plugins to 64-bit.
Documentation¶
Overview, choosing a development methodology, differences between Acrobat and Reader, example features, FAQ
A guide to the sample code included with the Acrobat SDK.
Developing plugins for Acrobat and Acrobat Reader, as well as for PDF Library applications.
Prototyping code without the overhead of writing and verifying a complete plugin or application.
Enabling Acrobat to save documents in a customized text-based format.
Using DDE, OLE, Apple events, and AppleScript to control the app and to render Adobe PDF documents, including detailed descriptions of DDE, OLE, Apple event, and AppleScript APIs.
Using JavaScript to develop and enhance standard workflows in Acrobat and Acrobat Reader.
Detailed descriptions of JavaScript APIs for developing and enhancing workflows in Acrobat and Acrobat Reader.
Detailed descriptions of JavaScript APIs for adding interactivity to 3D annotations within PDF documents.
Using RSS to track remote resources in an occasionally-connected environment.
Detailed descriptions of APIs for controlling Acrobat Distiller for PDF file creation.
Specifying settings for the creation of PDF files.
A detailed description of an extension to the PostScript language which allows the description of PDF features not found in standard PostScript.
Detailed descriptions of the APIs for using assistive technology with PDF documents.
Using JavaScript to perform repetitive operations on a collection of files.
A description of the APIs which help you develop Adobe Acrobat plug-ins and PDF Library applications.
A description of the APIs which help you develop Adobe Acrobat plug-ins and PDF Library applications.
PDF Reference¶
2015 HTML docs (12.x)¶
While legacy docs are deprecated, much of the information is identical and remains online. If you use it, keep it mind it does not contain the latest information, and references to Unix, LiveCycle, and other deprecated features have not been removed.
11.x and earlier documentation¶
Deprecated documentation (11.x and earlier) is not available online. For access to other versions of the developer documentation, contact acrobat-sdk-users @ adobe . com.
Приложения AIR можно создавать с помощью следующих инструментов платформы Adobe Flash Platform.
Для разработчиков ActionScript 3.0 (Flash и Flex):
Adobe Flash Professional (см. веб-страницу «Публикация для AIR»)
Комплекты SDK Adobe Flex 3.x и 4.x (см. разделы «Настройка Flex SDK» и «AIR Developer Tool (ADT)»)
Для разработчиков HTML и Ajax:
Adobe Dreamweaver CS3, CS4, CS5 (см. раздел «Расширение AIR для Dreamweaver)
Установка AIR SDK
В состав SDK Adobe AIR входят следующие инструменты командной строки для запуска и упаковки приложений.
AIR Debug Launcher (ADL) Позволяет запускать приложения AIR, не устанавливая их. См. раздел «AIR Debug Launcher (ADL)».
AIR Development Tool (ADT) Предназначен для упаковки приложений AIR в развертываемые установочные пакеты. См. раздел «AIR Developer Tool (ADT)».
Для запуска инструмента ADT требуется не менее 2 ГБ памяти на компьютере.
Краткий обзор создания приложения AIR с помощью AIR SDK см. в разделе «Создание первого HTML-приложения AIR с помощью комплекта AIR SDK».
Загрузка и установка AIR SDK
Ниже описано, как загрузить и установить AIR SDK:
Установка AIR SDK в ОС Windows
Загрузите установочный файл AIR SDK.
AIR SDK распространяется в виде стандартного файла архива. Чтобы установить AIR, извлеките содержимое SDK в папку на компьютере (например, в C:\Program Files\Adobe\AIRSDK или C:\AIRSDK).
Инструменты ADL и ADT содержатся в папке bin комплекта AIR SDK; добавьте этот путь в переменную среды PATH.
Установка AIR SDK в ОС Mac OS X
Загрузите установочный файл AIR SDK.
AIR SDK распространяется в виде стандартного файла архива. Чтобы установить AIR, извлеките содержимое SDK в папку на компьютере (например, в: /Users//Applications/AIRSDK).
Инструменты ADL и ADT содержатся в папке bin комплекта AIR SDK; добавьте этот путь в переменную среды PATH.
Установка AIR SDK в ОС Linux
Пакет SDK доступен в формате tbz2.
Чтобы установить SDK, создайте папку и распакуйте в нее содержимое SDK, используя команду tar -jxvf
Сведения о начале работы с инструментами AIR SDK см. в разделе «Создание приложения AIR с помощью инструментов командной строки».
Состав пакета AIR SDK
В таблице ниже приводится описание файлов пакета AIR SDK:
AIR Debug Launcher (ADL) позволяет запустить приложение без предварительной упаковки и установки. Дополнительные сведения см. в разделе «AIR Debug Launcher (ADL)».
AIR Developer Tool (ADT) упаковывает приложение в AIR-файл для распространения. Дополнительные сведения об использовании инструмента см. в разделе «AIR Developer Tool (ADT)».
Каталог libs содержит библиотеки кодов, используемые в приложениях AIR.
Каталог projects содержит код для скомпилированных библиотек SWF и SWC.
Включенный каталог содержит файл заголовка на языке C для написания собственных расширений.
Каталог install содержит USB-драйверы Windows для устройств Android (эти драйверы Google предоставляет в составе пакета Android SDK).
Содержит код поддержки для инструментов AIR SDK.
Среда выполнения AIR для настольных компьютеров и мобильных устройств.
ADL использует среду выполнения на настольном компьютере для запуска приложений AIR до их распаковки или установки.
Среду выполнения AIR для Android (пакеты APK) можно устанавливать на устройства Android и в эмуляторы для разработки и тестирования. Отдельные пакеты APK используются для устройств и эмуляторов (общедоступную версию среды выполнения AIR for Android можно загрузить с Android Маркета).
В этой папке содержится пример файла дескриптора приложения, пример функции незаметной установки (badge.swf), а также значки приложения AIR по умолчанию.
descriptor-template.xml — шаблон файла дескриптора приложения, необходимого для каждого приложения AIR. Подробное описание файла дескриптора приложения см. в разделе «Файлы дескриптора приложения AIR».
В этом каталоге также расположены файлы схемы для XML-структуры дескриптора приложения для каждой рабочей версии AIR.
Настройка Flex SDK
Создать приложение Adobe® AIR® с помощью Adobe® Flex™ можно одним из следующих способов.
Можно загрузить и установить пакет Adobe® Flash® Builder™, в котором содержатся инструменты для создания проектов Adobe AIR, их проверки, отладки и упаковки приложений AIR. См. раздел «Создание первого настольного приложения Flex AIR с помощью Flash Builder».
Можно загрузить Adobe® Flex™ SDK и разрабатывать приложения Flex AIR с помощью привычного текстового редактора и инструментов командной строки.
Краткий обзор создания приложения AIR с помощью Flex SDK см. в разделе «Создание первого настольного приложения AIR с использованием пакета Flex SDK».
Установка Flex SDK
В состав Flex SDK входят инструменты командной строки для упаковки, компиляции и отладки приложений AIR.
Распакуйте содержимое SDK в папку (например, во Flex SDK).
Скопируйте содержимое AIR SDK, заменив файлы в папке Flex SDK.
Примечание. На компьютерах Mac следует скопировать или заменить отдельные файлы в папках SDK, а не все каталоги. По умолчанию на Mac при копировании каталога в папку с таким же именем существующие файлы в целевом каталоге удаляются, то есть слияние двух каталогов не выполняется. Можно использовать команду ditto в окне терминала для объединения пакета AIR SDK с пакетом Flex SDK: ditto air_sdk_folder flex_sdk_folder
Инструменты командной строки AIR находятся в папке bin.
Настройка внешних SDK
Чтобы приступить к разработке приложений для Android и iOS, необходимо загрузить файлы обеспечения, пакеты SDK и другие инструменты разработки, предоставляемые производителями платформы.
Дополнительные сведения по загрузке и установке Android SDK см. в разделе «Разработчики Android: установка SDK». Начиная с версии AIR 2.6 загружать Android SDK больше не требуется. AIR SDK теперь содержит базовые компоненты, необходимые для установки и запуска пакетов APK. Тем не менее, Android SDK можно использовать для выполнения различных задач разработки, включая создание и запуск программных эмуляторов и получение моментальных снимков экрана устройства.
Внешний SDK для разработки приложений для iOS не требуется. Однако необходимы специальные сертификаты и профили поставки. Дополнительные сведения см. в разделе Получение файлов разработчика у компании Apple.
На посты, размещаемые в Twitter™ и Facebook, условия Creative Commons не распространяются.
Наша компания делает сервис для хранения и обработки данных с промышленных устройств (насосы, буры и прочая промышленная техника). Мы храним данные наших клиентов и предоставляем функционал для их анализа: построение отчетов, графиков и еще много чего.
И в ходе работы мы заметили, что интеграция каждого нового клиента сильно затягивается, а количество различных ошибок постоянно возрастает. Тогда стало понятно, что пора с этим разобраться. Как показал анализ ситуации, IT отдел каждого нашего клиента разрабатывал свое решение для локального сбора данных с устройств и отправки к нам в сервис. Все усложняет то, что с учетом специфики отрасли, не всегда есть доступ к интернету и необходимо хранить данные локально и отправлять при первой возможности. И таких нюансов достаточно большое количество, что и приводит к росту количества ошибок.
И тогда мы поняли, что лучшим решением в данной ситуации будет разработать SDK и предоставлять его клиенту. Сразу же начал искать лучшие практики и рассуждения на тему разработки SDK и сильно удивился — в рунете об этом практически ничего нет, а в басурманских интернетах очень мало информации и она разрознена. Ну что ж, задача понятна, обдумана и реализована.
Пора определяться
Начнем с того, что определим, что такое SDK и зачем он может быть нужен.
SDK (от англ. software development kit) — комплект средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определённого пакета программ, программного обеспечения базовых средств разработки, аппаратной платформы, компьютерной системы, игровых консолей, операционных систем и прочих платформ. SDK использует преимущества каждой платформы и сокращает время на интеграцию.
…
Инженер-программист обычно получает SDK от разработчика целевой системы.
Что ж, логично. Простыми словами, SDK — это пакет библиотек, для того, чтобы клиент мог легко и быстро начать работать с вашей системой (в данной статье речь пойдет про наш сервис, но всё изложенное в статье применимо и к другим видам SDK) или выполнять однотипные действия.
Но, как и у любого подхода, у "Пути SDK" есть как преимущества, так и недостатки.
Преимущества
Высокая скорость интеграции нового клиента — вашим клиентам нужно писать меньше кода.
Переиспользование кода — один и тот же код используется сразу в нескольких местах. Можно сказать, что это дублирование предыдущего пункта, но речь идет о том, что логика работы везде одинокава, из чего следует
Предсказуемость поведения — использование одних и тех же библиотек приводит поведение систем к определенному стандарту, что сильно облегчает поиск и устранение ошибок и уязвимостей.
Качество кода — много где любят экономить на тестировании (жалко бюджета, горят сроки и прочие причины). Понятно, что в реальном мире покрыть тестами все участки проекта это учень трудоемкая задача. Но качественно протестировать все модули SDK, а затем использовать их — это путь повышения процента покрытия тестами, что приведет вас к снижению количества ошибок.
Документация — тот же сценарий, что и с тестами. Покрыть документацией весь проект достаточно проблематично. Переиспользование модулей SDK повышает процент покрытия документацией, что снижает порог вхождения новых сотрудников в проект и вообще помогает по жизни.
Все преимущества, по сути, это следствия самого главного — мы очень качественно пишем код один раз, а затем его переиспользуем.
Недостатки
Высокие требования к качеству кода SDK — следствие главного преимущества. Ошибка в SDK породит ошибки во всех системах, его использующих.
Установка ограничений — SDK — это набор библиотек для реализации стандартных сценариев. Иногда разработчики SDK полагают, что кроме реализации одного из предусмотренных сценариев клиенту ничего не потребуется, что клиенту проще сделать все с нуля самостоятельно, чем строить пьедестал из костылей для SDK.
Dependency hell и обновления — при расширении функционала (например, кастомизации решения под конкретного клиента), вы выпустите новую версию библиотеки. Но существуют зависимости, различные наборы версий библиотек у разных клиентов, и нужно очень тщательно следить за обратной совместимостью или строгим версионированием.
Когда SDK действительно нужен
У вас есть несколько стандартных сценариев, которые реализуются заново из раза в раз — собственно, наш случай.
Когда SDK скорее всего будет лишним
Сценарии использования не определены или постоянно меняются — оставьте реализацию кастомных решений клиентам и помогите им. Не надо городить вундервафлю, которая будет только мешать. Очень актуально для молодых компаний и стартапов.
Вы не умеете делать качественно — у меня для вас плохая новость: пора учиться. Но отдавать кривое решение клиенту это очень, очень неправильно. Клиентов надо уважать, в конце концов.
Итак, мы определились, что такое SDK, с его преимуществами и недостатками и когда он нам нужен. Если после этого вы поняли, что SDK действительно нужен — приглашаю вас встать на "путь SDK" и разобраться, а каким он должен быть и как его, черт подери, делать?
"А вы любите Lego?" — Модульность
Представим все возможные сценарии использования SDK (вы же уже определились, зачем он вам нужен, правда?) и сделаем по библиотеке на сценарий. Чем не выход? Но это плохой подход, и так мы делать не будем. А будем так:
- разобьем все сценарии на шаги
- выявим общие шаги
- построим список модулей, реализующих все возможные шаги (один модуль отвечает за реализацию чего-то конкретного, например, работы с конфигурациями)
Например, с учетом специфики задачи, нам необходимо, чтобы вся логика задавалась из конфигов. Реализуем модуль работы с конфигами (чтения, записи, обновления, валидации и обработки конфигураций) и будем использовать его во всех остальных модулях.
А для реализации стандартных сценариев мы действительно сделаем модули — этакие "управляющие" модули, каждый из которых реализуют один конкретный сценарий, используя другие модули того же SDK. Таким образом для реализации стандартных сценариев клиент должен лишь подключить управляющий модуль сценария (а он сам подтянет все зависимости), а для реализации нестандартных — используем базовые модули, так же переиспользуя код.
Именно этим обусловлено то, что SDK не должен быть одной библиотекой (хотя очень хочется, понимаю. Ведь когда весь SDK в одной библиотеке, можно забыть о зависимостях и всем, что с ними связано), а быть комплектом библиотек. Дополнительным плюсом данного подхода будет уменьшение "веса" программы клиента — он будет тянуть тяжеловесный SDK, а подтянет только необходимые модули.
Но не стоить плодить модули как попало, ведь чем больше модулей, тем больше головной боли от их зависимостей! Т.е. важно правильно разбить логику на модули, соблюдая баланс между решением "все в одном" и "на каждую функцию свой модуль".
"А что, так можно было?!" — Универсальность
Предоставьте клиенту различные интерфейсы для работы с вашей библиотекой. Приведу пример:
Если предоставить только синхронную версию, то при реализации асинхронного приложения клиент вынужден будет делать асинхронные обертки вашего синхронного метода. Если предоставить только асинхронную версию — ситуация похожа. Дайте клиенту и то и другое и он скажет вам спасибо.
Приятным плюсом будут дженерики. Например, у нас есть класс для работы с конфигурациями, реализующий методы упаковки конфига в строку, загрузки конфига из файла и т.д. Конфигурация конкретного модуля будет наследоваться от нашего базового класса, но для работы с новым классом нам необходимо также предоставить методы распаковки.
Таким образом мы предоставили клиенту аж три реализации, которые он может использовать. Дженерики очень удобны, но при работе с динамическими типами их можно вызывать только через рефлексию, что накладно. Общий принцип универсальности, надеюсь, понятен.
"Родитель 1, Родитель 2, Дети[ ]" — Именование
И тем не менее… Правильное именование модулей, классов, свойств и методов сильно помогут тем, кто будут с вашим SDK работать. Пример, не требующих комментариев:
Kinect 2.0 SDK example
Всё ясно из названий классов и методов. А если есть автодополнение кода в вашей IDE, то зачастую можно и в документацию не заглядывать, если и так все понятно.
"Уверен, если бы Смерть знала, что такое бюрократия, люди бы никогда не умирали, вечно стоя в очереди. " — Документация
Но даже если у вас очень красиво и актуально названы все модули, классы, методы и свойства, документацию все равно необходимо написать. Во-первых, это очень сильно сбережет вам нервы (количество вопросов клиентов уменьшается на порядок. Все есть в документации), а во-вторых, всегда понятно, почему вы сделали так, а не иначе.
Документация, в SDK, как правило, проста и лаконична. Она обычно делится на две части: Tutorial — пошаговый курс в стиле “Построим город за 10 минут” и раздел Reference — справочник по всему, что можно сделать с помощью данного SDK.
Мы выбрали самый простой путь — summary + articles. Мы добавляем Xml атрибуты для методов и классов, которые светятся в intellisense как подсказки. Используя Docfx мы строим документацию по этим атрибутам и получаем подробную и удобную документацию, которую дополняет статьями, описывающими сценарии использования и примеры.
"— Чтобы чисто было! — Как я буду вилкой-то чистить?" — Тестирование
Что можно сказать про тестирование в рамках обсуждения SDK… Must have! Лучшим решением будет TDD (несмотря на то, что я негативно отношусь к данному подходу, в данном случае я решил использовать именно его). Да, долго. Да, нудно. Но зато в будущем вы не повеситесь от постоянных падений SDK на стороне и следствий этого падения.
Основной сок ситуации заключается в том, что отдавая SDK клиенту вы теряете контроль: вы не можете быстро пофиксить ошибку, сложно эту самую ошибку найти, да и выглядеть в такой ситуации вы будете достаточно глупо. Поэтому — тестируйте. Тестируйте лучше. И еще раз. И, на всякий случай, протестируйте ваши тесты. И тесты тестов. Так, что-то я увлекся, но важность тестирования SDK, надеюсь, понятна.
"Жертва, которая не могла противостоять своему прошлому, была поглощена им" — Логи
Поскольку вы отдаете SDK сторонней компании, в следствие чего теряете контроль над ситуацией, в случае ошибки (на этапе тестирования вы все-так решили "и так сойдёт", да?) вас ждет достаточно долгий и болезненный процесс поиск этой самой ошибки. Именно тут вам на помощь придут логи.
Логируйте все, абсолютно все, а в случае возникновения ошибки запросите у вашего клиента логи. Таким образом вы сэкономите много времени и сможете не потярять лицо перед клиентом.
"Alarm! Achtung! Attention!" — Ошибки
Долго размышляя на тему ошибок я пришел к интересному выводу — ни один метод в вашем SDK не должен отдавать ошибку, не описанную в документации. Согласитесь, очень неприятно, когда вы подключаете стороннюю библиотеку для работы с HttpRequest, а она вываливает на вас какой-нибудь NullPointerException и StackTrace, который уводит в недра библиотеки. И вам приходиться погружаться в эти самые "недра", пытаясь понять, насколько глубока кроличья нора, и в чем, собственно, проблема.
Поэтому я предлагаю следующее решение — декларируйте закрытый список возможных исключений и документируйте их. Но, т.к. нельзя быть увереннным, что вы предусмотрели все, оберните метод в try-catch, а пойманную ошибку — в задекларируему. Например, ConfigurationException, который будет содержать InnerException — пойманную ошибку. Это позволит стороннему разработчику поймать все возможные ошибки, но в случае чего быстро разобраться в чем дело.
Версии или "как не укусить себя за хвост"
Во избежание проблем в будущем крайне рекомендую использовать строгое версионирование. Выберете подходящую вам систему построения версий и используйте ее. Но если новая версия библиотеки не имеет обратной совместимости — это необходимо указать. Как это разруливать — думать вам. Но подумать об этом точно стоит.
"Паровозик, который смог" — Deploy
Необходимость актуальности документации и версий порождают требование к корректности деплоя. В своем решении мы используем следующее решение (костыли, но работают).
Когда надо выпустить нвый релиз, разработчик дергает bat'ник с указанием номера релиза, а затем батник:
- билдит релиз
- кладет все библиотеки в архив
- билдит свежую версию документации (docfx)
- указывает версию релиза в документации и в названии архива
- кладет всё самое свеженькое в гит-репозиторий
- WebApp на MS Azure подтягивает свежий коммит по гит хуку и публикует изменения
На выходе получаем обновленную версию сайта с документацией, откуда можно скачать архив с последней версией SDK.
В планах на будущее — упаковка всего в Nuget пакеты и публикация в локальный Nuget репозиторий.
Рекоммендую обратить внимание на этот пункт, ведь вы можете существенно снизить количество головной боли, вызванной отсутствием актуальной информации о новой версии библиотеки.
"-А так можешь? — Фигня. Смотри как надо!" — Примеры & toolkit
Важным пунктом документации являются примеры использования. Но помимо этого, зачастую требуется предоставить не библиотеку, а приложение, которое реализует самые стандартные сценарии. Рекомендую делать эти приложения с открытым и хорошо прокомментированным исходным кодом, что позволит убить двух зайцев разом — предоставить работающее приложение и предоставить пример использования SDK.
Заключение
Разработка SDK стало для меня интересной новой задачей, поднявшей много важных архитектурных вопросов. Многое описанное в статье является очевидными вещами (для меня), но считаю важным огласить даже очевидные вещи, чтобы получить четкую общую картину.
Спасибо за прочтение, буду рад вашим комментариям. Надеюсь, эта статья будет для вас полезной.
В этой статье я расскажу как при помощи HTML и JavaScript сделать своё собственное расширение для Photoshop, Illustrator, Premier, Flash, Prelude или InDesign.
С июня 2013-го года Adobe добавила поддержку HTML5 для расширений, тем самым упростив их создание.
Сразу замечу, что сам я дизайнер и к программированию имею очень посредственное отношение, так что прошу прощения за возможные ошибки в терминологии.
Инструменты
Для работы нам понадобятся любимый текстовый редактор и базовые знания HTML, CSS и JavaScript.
Да-да, теперь никаких Adobe Configurator и Flash.
Автоматизировать создание базового набора нужных файлов помогут Eclipse и Brackets/Edge Code CC.
Из чего состоит
Создадим простейшее расширение для Photoshop.
Минимальный набор файлов и их структура такие:
где manifest.xml — файл с описанием всех его параметров,
а index.html — само расширение.
Manifest.xml содержить примерно следуюшее
а в index.html, всё что душе угодно. Например:
Вот и всё.
Наше первое расширение готово.
Запуск
Для запуска неподписанных приложений нужно включить PlayerDebugMode.
Для этого нужно добавить ключ PlayerDebugMod со значением String равным 1
Далее папку с созданным расширением нужно положить сюда
Запустить Фотошоп и выбрать в меню Window > Extensions > наше расширение
Все дальнейшие изменения можно вносить прямо в папке CEPServiceManager4\extensions.
О том как вносить изменения без перезапуска Фотошопа ниже
Debugging
Для того, чтобы включить этот режим нужно создать в корневой папке расширения файл .debug,
содержание которого примерно следующее
где Extension — ID нашего расширения,
а Port=«8088» — порт для подключения.
выберем наш index.html.
И вот они Developer Tools
Проверено в Safari и Chrome
Инструменты упрощающие жизнь
Adobe Edge Code CC/Brackets
- все нужные файлы в нужном месте для Photoshop, Illustrator, Premier, Flash, Prelude или InDesign на выбор
- библиотеки jQuery и CSInterface
- шаблон для иконки
- свою библиотеку оформления всех элементов интерфейса в стиле Adobe
- скрипт автоматического перекрашивания панели в цвет интерфейса приложения
- кнопочку «Refresh»
- .debug со всеми прописанными данными
После установки расширения в Edge Code CC выбираем File > New Creative Cloud Extension
Вносим нужные правки в index.html
Сохраняем. Запускаем фотошоп и открываем то, что получилось.
Обратите внимание на маленькую кнопочку «Rf» в правом верхнем углу — она позволяет перезагружать расширение без перезагрузки фотошопа.
Кстати, все скрипты работающие непосредственно с функциональностью фотошопа хранятся в папке jsx папки расширения.
Eclipse
Для этого редактора скачиваем это дополнениеAdobe Extension Builder 3 и устанавливаем его.
- шаблоны для Photoshop, Illustrator, Premier, Flash, Prelude или InDesign
- библиотеки jQuery и CSInterface
- свою библиотеку оформления всех элементов интерфейса в стиле Adobe
- скрипт автоматического перекрашивания расширения в цвет интерфейса приложения
Суть примерно такая же как и в первом случае.
Только вот очень неудобно, что для просмотра внесённых изменений нужно каждый раз перезапускать фотшоп.
Также нет иконки и .debug-файла.
Да и сам Eclipse тяжелее на подъём.
Сборка в ZXP
Последний этап — собрать результат в ZXP-файл и подписать его.
За неимением под рукой Windows, расскажу как это делается в OS X.
Для этого скачиваем CC Extensions Signing Toolkit
Открываем терминал и получаем сертификат командой
пример
Полсле того, как сертификат получен пакуем наше расширение в ZXP с использованием этого сертификата.
На этом всё.
Надеюсь, статья поможет многим сделать первый шаг в сторону разработки своих улучшений всеми известных программ.
Полезные ссылки
HTML Panel Tips by Davide Barranca — несколько полезных статей на тему
Introduction To Photoshop Scripting By Kamil Khadeyev — с чего начать свой первый скрипт для Фотошопа.
USING The Adobe Eextension SDK — подробная инструкция от Adobe
Adobe Photoshop Scripting — документация по написанию скриптов от Adobe
A Short Guide to HTML5 Extensibility — примерно тоже, что я описал в первой части своей статьи
Introducing HTML5 Extensions — пара вводных видео для работы с Eclipse
Adobe Extension Builder 3 — расширение для Eclipse и паковщик в ZXP-файлы
Creative Cloud Extension Builder for Brackets — расширение для Adobe Edge Code CC/Brackets
Читайте также: