Pull to refresh

Comments 21

Вот бы для android такое же :))) Вообще конечно супер, всегда приятно избавиться от рутины.
UFO just landed and posted this here
Код конечно неюзабельный.
Приходится импортировать и вытаскивать все значимые вещи.
В итоге получается все как обычно, руками вынимать и фильтровать тот мусор что генерит визуальный редактор, в этом свете заявление:
Не секрет, что создание дизайна приложения под Windows Phone или Windows 8 занимает гораздо меньше времени, чем под iOS или Android.

может и верно, но скорее всего экономия где-то в другом месте.
Могу ошибаться, но вроде как android и iOS не умеют импортировать макеты psd в нативные контролы.
«Вытаскивать значимые вещи» это не совсем фильтровать руками, это просто причесывание к нашему code style и более логичная компоновка. Те же самые path мы импортируем 1 к 1.
Так а с таким сценарием наоборот следует избегать затрагивать код. От дизайнера требуется открыть общий солюшен, где девелоперы набросали рыбу разметки. Далее он должен с сохранением биндингов переделать разметку, темплейты и прочие дизайновые вещи.
Потому и важно следовать паттерну MVVM, чтоб можно было легко делать дизайн минуя код.
Пробовал как то такой подход + делать дизайн в бленде с нуля.
Код получается просто отвратительный, с кучей мусора. Нужно потратить не мало времени, что бы привести все в порядок. Не говоря уже о анимации.
Хотя если не заморачиваться так сильно, то получается быстрее и проще, чем руками в студии.
Если речь идет о XAML (кодом в таких проектах принято называть C#), то работа в Blend с нуля дает чистую, логичную и очень экономную разметку. И это не идеал, как написано в статье, а норма.
Необходимые условия: знание xaml, понимание разных типов панелей лейаутов, широкое применение принципов наследования и каскадирования.
Ну у меня достаточно опыта утверждать обратное.
«дает чистую, логичную и очень экономную разметку»
Для «Hello, world», да. Попробуйте написать что то отличное от него и рсс ридера. Я уж не говорю о том, что бы сделать свой кастумный контрол. Ну например листбокс с пушем. Или текст бокс с вотермарком и кликабельной иконкой. Не о какой чистоте и логичности там и речи нет.
Может в новом бленде что то и поменялось, но очень сильно сомневаюсь.
— Никаких проблем. Я — дизайнер WPF и отвечаю за 33 стандартных контрола и всю графику, которую делаю в Blend, без иллюстратора и фотошопа.
Если нужем кастомный контрол, девелоперы напишут в VS, а я в Blend'e придам ему любой вид, какой понадобится.
Не помню, чтоб я когда-нибудь делал текст бокс с вотермарком, но глянул в сети и ничего сложного не нашел: stackoverflow.com/questions/5593649/help-text-in-wpf-textbox-that-disppears-after-first-input-watermark-the-xaml
Кликабельная иконка — вещь чрезвычайно простая, я помещаю иконки в прозрачные кнопки, чтобы навешивать анимацию на триггеры.
Импорт векторных объектов в бленд не очень хорошая идея, так как это плохо сказывается на производительности приложения. Конечно пара векторных квадратов не повлияют особо, но что то более сложное значительно ухудшит производительность, поэтому дешевле (в плане ресурсов) использовать растр и перед переносом просто растрировать всю необходимую графику.

И еще хочу отметить, что такой способ «отказа от нарезки» подойдет больше для прототипирования и небольших проектов. Все же с серьезными и большими приложениями удобнее иметь библиотеку ресурсов и нарезать ее отдельно.
В статье показан как раз большой проект, спортс.ру для Windows Phone.
удобнее иметь библиотеку ресурсов

Этот подход не отменяет ресурсы стили и другие удобные вещи, если я конечно правильно понял вас.
Те же цвета выносятся в ресурсы двумя кликами.
К сожалению не все до конца так радужно. Да, во многом это очень сильно упрощает работу дизайнеру и программисту для понимания, но когда в приложении сложные механизмы UI (анимации, поведения, обновления и тп.) то вот просто взять и импортировать PSD файл и тут же его использовать не получится.

И как уже сказали, path сильно влияет на производительность, поэтому даже в MSDN советуют использовать картинки, ко всему прочему советуют jpg, а к png использовать только при необходимости (например прозрачность).
«И как уже сказали, path сильно влияет на производительность, поэтому даже в MSDN советуют использовать картинки»
На MSDN в статье по улучшению производительности советуют включать растровое кэширование. Ну и, конечно, иконки растровые вместо векторных. В этом плане можно с Expression Designer поработать.

«К сожалению не все до конца так радужно. Да, во многом это очень сильно упрощает работу дизайнеру и программисту для понимания, но когда в приложении сложные механизмы UI (анимации, поведения, обновления и тп.)»
Если несложно, то приведите конкретный пример. Я интуитивно и по опыту подозреваю (почти уверен), что Вы правы, но все же хочется разобраться на конкретном примере. Может есть обходной путь.
Пример, это когда у дизайнера очень интересная и клевая идея контрола, который не является нативным для системы. (особенно часто это появляется, когда портируют приложение с iOS к примеру на Windows Phone и поведение на экранах должно быть одинаковым либо сильно приближенным)

Или давайте на том же примере, что показан выше, в том месте где «статистика» есть выбор по какому столбцу сортировать. И к примеру, необходимо, при выборе определенного столбца белую стрелку снизу указывающую на сортируемый столбец перемещать с использованием анимации (в 0,5 сек) при этом сами элементы внутри списка также с анимацией должны сортироваться.

Если хотите подскажу реальный пример в одном приложении. Обращайтесь в личку, чтобы не сочли за рекламу:)
Я примерно понял. Я бы попытался отнаследоваться от некоего контрола, вынуть наружу DependencyProperty с темплейтом кастомного маркера и анимации для нее, выдал бы дизайнеру инструкции по пользованию контролом и переопределению темплейтов и анимаций. Но вообще да — полет фантазии дизайнера трудно обуздать и сложно поддерживать.
Вот еще пришло в голову. При импорте все слои импортируются как Canvas. но это далеко не всегда разумно, поэтому приходится в последствии вручную переделывать на Grid или StackPanel.
И как уже сказали, path сильно влияет на производительность

Дольше грузится, причем только на wp7. А потом path кэшируется и на fps влияет не существенно.
Я всегда оставляю все в векторе, ибо это оптимизация не стоит того. Зато 1 сборка приложения на все устройства без возни с растром.
Не возиться с растром — конечно подкупает в такие моменты. Особенно с поддержкой разных разрешений.
Судя по заголовку подумал что здесь описание работы с блендом при создании приложения для винфон, а здесь огромная статья о том как перекинуть файлы из фотошопа в бленд. Хотя бы заголовок более корректный сделайте…
А как обстоит дело при разработке продуктов для iOS? Если можно ссылку или поясните, а то толком ничего не нахожу на эту тему, а вы видимо в курсе, судя по «не секрет, что...».
Sign up to leave a comment.