Автоматическая генерация ресурсов для приложений Android с помощью скриптов для Adobe Photoshop

[@VYakushev]

detectFolder здесь не привожу, так как ничего особенного в ней нет: функция проверяет, есть ли в надпапке папки документа папка res, и возвращает ее, если находит, а если нет, то спрашивает пользователя.

А, если в указанной папке для сохранения ресурсов нет заранее созданных папок под все разрешения, то они будут созданы?

[@DrMetallius]

Разумеется. Это происходит в функции createFile, которую я не приводил.

[@VYakushev]

Понял, спасибо. Использую "Cut&Slice me", но не хватает генерации ресурсов на xxhdpi. Попробую пользоваться вашими скриптами.

[@DrMetallius]

Интересный инструмент, кстати. Когда я смотрел на то, что вообще доступно на эту тему, мне он не попадался. Но там автоматизация, насколько я понял, несколько другого рода, да и стили он сам не применяет. У меня-то как бывает: я нарисую несколько иконок, просто один слой в каждом файле. Потом в скрипте описываю, какие стили слоя я хочу видеть для каждого состояния, применяю сразу ко всем иконкам, и у меня на выходе из каждого однослойного документа сразу штук 30 автоматически сгенерированных ресурсов. А там, судя по описанию, стили надо вручную рисовать для каждой иконки и ставить по отдельному слою на состояние. Это все равно прилично работы.

[@sagus]

Я для себя подобное на bash написал github.com/oleonov/make_resources_android

[@VYakushev]

Называть это подобным неправильно, т.к. в вашем случае ресайзятся растровые изображения, а в данном случае — вектор:

Ну и, разумеется, изображение должно быть векторное, а не растровое, иначе нет особого смысла в масштабировании его средствами Photoshop, а не Android.

[@sagus]

Да, мой вариант для растровых. Не всегда есть вектор, ну и в большинстве случаев потери качества просто не видно.
Но вектор несомненно лучше)

[@DrMetallius]

У меня дело не только в векторе, мне еще нужно применять стили и обрабатывать nine-patch. Изначально-то, конечно, все и у меня примерно так же было: есть изображение, надо сохранить в разных размерах. Но каждую кнопку рисовать в нескольких состояниях — это довольно утомительно. Значит, нужно создавать применение стилей. Еще нужно сделать кнопки растягиваемые — делаю обработку nine-patch. Потом надоело XML прописывать вручную — пишу код, чтобы он генерировался сам. Вот так и получилось то, что есть в итоге.

Раньше, кстати, еще была необходимость в том, чтобы иконки рисовались под разные версии Android. Например, на версии 2.3 и ранее были меню, где использовались те же иконки, которые сейчас сидят в панели действий. Но требования к их стилю были другие, поэтому надо было еще сохранять по два варианта иконки на каждый. Сейчас Google наконец-то сделали официальную библиотеку, в которой есть поддержка панели действий на Android 2.1 и выше, так что теперь нужда в этом точно отпала. А кроме меню были еще те же самые проблемы и у других элементов, таких как иконки для уведомлений и вкладок. К счастью, это тоже уже перестало быть нужным, и довольно давно, особенно в случае вкладок.

[@Yurevich1]

Приведите, пожалуйста, пример, чем этот скрипт выгоднее, чем стандартные Action — > Automate хуже?
Буду рад, если будут какие-то картинки. Лично мне(думаю, что не только мне) не очень понятно, зачем это нужно.

[@DrMetallius]

Могу перечислить проблемы с дроплетами и действиями:

• Нет работы с относительными путями;
• Нет работы с префиксами ("_normal", "_focused", "_disabled" и т.п.);
• Невозможна обработка nine-patch;
• Нельзя автоматически генерировать XML.

Самые важные — это первые два пункта: нет поддержки относительных путей, и в каждом отдельном дроплете один постфикс на все про все. В итоге даже в самом простом случае это означает, что на каждую пиксельную плотность и для каждого проекта нужно писать по дроплету, потому что финальная папка должна быть прописана заранее, абсолютным путем. Можно, конечно, и так делать, но что это за автоматизация?

А если в ресурсе несколько состояний, то нужно писать по дроплету еще и на состояние кнопки в определенной пиксельной плотности. Если у нас 5 плотностей и 6 состояний кнопки, это 5 × 6 = 30 дроплетов, что уже вообще никуда не годится.