Comments 11
detectFolder здесь не привожу, так как ничего особенного в ней нет: функция проверяет, есть ли в надпапке папки документа папка res, и возвращает ее, если находит, а если нет, то спрашивает пользователя.
А, если в указанной папке для сохранения ресурсов нет заранее созданных папок под все разрешения, то они будут созданы?
Разумеется. Это происходит в функции
createFile, которую я не приводил.Понял, спасибо. Использую "Cut&Slice me", но не хватает генерации ресурсов на xxhdpi. Попробую пользоваться вашими скриптами.
Интересный инструмент, кстати. Когда я смотрел на то, что вообще доступно на эту тему, мне он не попадался. Но там автоматизация, насколько я понял, несколько другого рода, да и стили он сам не применяет. У меня-то как бывает: я нарисую несколько иконок, просто один слой в каждом файле. Потом в скрипте описываю, какие стили слоя я хочу видеть для каждого состояния, применяю сразу ко всем иконкам, и у меня на выходе из каждого однослойного документа сразу штук 30 автоматически сгенерированных ресурсов. А там, судя по описанию, стили надо вручную рисовать для каждой иконки и ставить по отдельному слою на состояние. Это все равно прилично работы.
Я для себя подобное на bash написал github.com/oleonov/make_resources_android
Называть это подобным неправильно, т.к. в вашем случае ресайзятся растровые изображения, а в данном случае — вектор:
Ну и, разумеется, изображение должно быть векторное, а не растровое, иначе нет особого смысла в масштабировании его средствами Photoshop, а не Android.
Да, мой вариант для растровых. Не всегда есть вектор, ну и в большинстве случаев потери качества просто не видно.
Но вектор несомненно лучше)
Но вектор несомненно лучше)
У меня дело не только в векторе, мне еще нужно применять стили и обрабатывать nine-patch. Изначально-то, конечно, все и у меня примерно так же было: есть изображение, надо сохранить в разных размерах. Но каждую кнопку рисовать в нескольких состояниях — это довольно утомительно. Значит, нужно создавать применение стилей. Еще нужно сделать кнопки растягиваемые — делаю обработку nine-patch. Потом надоело XML прописывать вручную — пишу код, чтобы он генерировался сам. Вот так и получилось то, что есть в итоге.
Раньше, кстати, еще была необходимость в том, чтобы иконки рисовались под разные версии Android. Например, на версии 2.3 и ранее были меню, где использовались те же иконки, которые сейчас сидят в панели действий. Но требования к их стилю были другие, поэтому надо было еще сохранять по два варианта иконки на каждый. Сейчас Google наконец-то сделали официальную библиотеку, в которой есть поддержка панели действий на Android 2.1 и выше, так что теперь нужда в этом точно отпала. А кроме меню были еще те же самые проблемы и у других элементов, таких как иконки для уведомлений и вкладок. К счастью, это тоже уже перестало быть нужным, и довольно давно, особенно в случае вкладок.
Раньше, кстати, еще была необходимость в том, чтобы иконки рисовались под разные версии Android. Например, на версии 2.3 и ранее были меню, где использовались те же иконки, которые сейчас сидят в панели действий. Но требования к их стилю были другие, поэтому надо было еще сохранять по два варианта иконки на каждый. Сейчас Google наконец-то сделали официальную библиотеку, в которой есть поддержка панели действий на Android 2.1 и выше, так что теперь нужда в этом точно отпала. А кроме меню были еще те же самые проблемы и у других элементов, таких как иконки для уведомлений и вкладок. К счастью, это тоже уже перестало быть нужным, и довольно давно, особенно в случае вкладок.
Приведите, пожалуйста, пример, чем этот скрипт выгоднее, чем стандартные Action — > Automate хуже?
Буду рад, если будут какие-то картинки. Лично мне(думаю, что не только мне) не очень понятно, зачем это нужно.
Буду рад, если будут какие-то картинки. Лично мне(думаю, что не только мне) не очень понятно, зачем это нужно.
UFO just landed and posted this here
Могу перечислить проблемы с дроплетами и действиями:
Самые важные — это первые два пункта: нет поддержки относительных путей, и в каждом отдельном дроплете один постфикс на все про все. В итоге даже в самом простом случае это означает, что на каждую пиксельную плотность и для каждого проекта нужно писать по дроплету, потому что финальная папка должна быть прописана заранее, абсолютным путем. Можно, конечно, и так делать, но что это за автоматизация?
А если в ресурсе несколько состояний, то нужно писать по дроплету еще и на состояние кнопки в определенной пиксельной плотности. Если у нас 5 плотностей и 6 состояний кнопки, это 5 × 6 = 30 дроплетов, что уже вообще никуда не годится.
- Нет работы с относительными путями;
- Нет работы с префиксами ("_normal", "_focused", "_disabled" и т.п.);
- Невозможна обработка nine-patch;
- Нельзя автоматически генерировать XML.
Самые важные — это первые два пункта: нет поддержки относительных путей, и в каждом отдельном дроплете один постфикс на все про все. В итоге даже в самом простом случае это означает, что на каждую пиксельную плотность и для каждого проекта нужно писать по дроплету, потому что финальная папка должна быть прописана заранее, абсолютным путем. Можно, конечно, и так делать, но что это за автоматизация?
А если в ресурсе несколько состояний, то нужно писать по дроплету еще и на состояние кнопки в определенной пиксельной плотности. Если у нас 5 плотностей и 6 состояний кнопки, это 5 × 6 = 30 дроплетов, что уже вообще никуда не годится.
Sign up to leave a comment.
Автоматическая генерация ресурсов для приложений Android с помощью скриптов для Adobe Photoshop