Как стать автором
Обновить

Комментарии 21

Картинок не хватает. А те что есть непропорционально большие.
… вы будете видеть приятную глазу картину.
можно так же заметить… изменения в интерфейсе.
Каких именно?
Именно тех, на которые ссылаетесь.

Еще из недостатков, что на приведенных риснуках не выключили отладочную информацию и панель. Глаза раздражает. Да и не имеет она никакого отношения к вашей статье.
Скрины заменили.

Насчет рисунков, оставлен специально такой масштаб, чтобы было максимально наглядно: маленькое и большое окно.
А как же способ с использованием DeviceFamily для указания различных платформ, такой способ более подходящий (https://habrahabr.ru/post/268695/), учитывая разный масштаб на устройствах. Не вижу тут никакого лайфхака.
Идея лайфхака в том, что не всегда нужно знать на каком устройстве выполняется приложение, что бы получить одинаковое поведение, о чем сказано в заключении. Да есть масса сценариев, когда DeviceFamily предпочтительней, но есть более простые сценарии, в которых DeviceFamily это усложнение. Прежде чем сделать Рубль Life я изучил статью, которую вы привели в качестве примера и счел ее усложнением для моего сценария. Мое решение проще и так же решает поставленную задачу. Приложение тестировалось на всех размерах от маленьких смартфонов, до больших телевизоров и везде смотрится приятно.
Ну для столь простого, то да. В более сложном приложении, это костыль по сути, усложняет View.
Так таких простых проектов полным полно. Изучая их я и решился на написание данной статьи.
Простой пример — программа со стихами некоего автора. Разработчик решил, что на мобильных устройствах он будет показывать список стихов в ListView, а на ПК и GridView. Все хорошо, пока не начинаются описанные в статье манипуляции. Описанное решение стоило бы ему пару лишних строчек и в корне изменило бы ситуацию, а решение с разделением по девайсам слишком больших усилий на которое он скорее всего не готов пойти.
Есть несколько идей для следующих статей из этой рубрики, что было бы интереснее для вас?

1. SettingsFlyout в UWP.
2. Стилизация и разработка элементов управления UWP.
3. Продвижение: как получить положительный отзыв.
Второе.
Вот вот, даже если использовать MVVM, то все равно не получается отдельно от кода работать.
Пожалуйста раскройте эту тему:
2. Стилизация и разработка собственных элементов управления UWP.

У меня есть потребность разобраться в создании нескольких элементов:
1. Первый: Графиков, диаграмм, как элемента управления, который можно было бы использовать в других проектах. Сейчас диаграмму реализовал в виде используя несколько элементов ItemControl и TextBlock, но это творение не является единым элементом управления.
2. Второй: Элемент для вывода отчетов с возможностью указания настраиваемых фильтров, группировок, периода. Например, нужно вывести отчет о клиентах и заказах, товарах в количестве и сумме. Подумываю вывести в виде таблицы используя Grid или в другом виде используя gridView, а для задания группировок и фильтров использовать ContentDialog. Хочется, чтобы это был некий единый элемент, который связываешь с данными, указываешь некую схему отображения, а он формирует и выводит.
3. ListView в виде иерархического дерева. Возможность раскрывать ветки и видеть содержимое.
4. Элемент, подобно ComboBox, но с векторными картинками (svg), без надписей и возможно с надписями. Картинки при раскрытии должны быть расположены по горизонтали и по вертикали.
Может это уже все есть готовое, тогда подскажите где?

Позже раскройте такие темы:
3.
Продвижение: как получить положительный отзыв

4. Синхронизация локальных данных базы SQLite и некой общей базы данных в Azure. Например, пользователь использует одно и тоже приложение на телефоне (в основном вводит данные) и на компьютере (больше анализирует собранные данные, обрабатывает).
5. Использование векторных картинок в виде пользовательских данных.
6. Голосовой ввод и использование Cortana.
Большое спасибо за фидбэк!
>упрощает разделение труда между дизайнером и разработчиком

Неужели есть конторы, где кто-то пишет только xaml, а кто-то только логику? Мне кажется в 99.9% верстку делает тот же разработчик.
Спрашиваю как uwp-dev.
>В частности, в версии для телефонов, повернув устройство в горизонтально положение, интерфейс не изменится, тогда как места вполне достаточно для отображения как списка писем, так и содержания письма по типу версии для ПК.
На 1520 при повороте в горизонтальное положение именно так и происходит — список слева, открытое письмо справа.
У меня консультировалась студентка, которая не написала не строчки кода, при этом защищалась по теме UWP дизайна. Для старичков все это кажется странным, а вот молодежь уже взращивается на идеях такого разделения труда.
Мы так работаем – обучили графического дизайнера xaml'у (абсолютно без навыков программирования — ни строчки на js даже не написал никогда), очень удачно втянулся в тонкости UX/UI дизайна и работает только со вьювами, без вмешательства программистов. Конечно, бывают случаи, когда помощь нужна – конвертер там написать, или особое поведение прописать в code-behind'е, но 99.99% случаев справляется сам.
Так удается обеспечить одинаковую логику и единый дизайн-язык всего UI. Плюс, у программистов меньше искушений писать логику под конкретный вью.
Интересно. Он умеет темплейты, стили, триггеры, бихевиоры?
Как он пишет байндинги? Вы даёте ему контракт вью-модели?
Да, темплейты, стили, триггеры, вижуал-стайлы, you name it.
Бихевиоры мы, правда, не ипользуем. Однажды пробовали в проекте под Windows Phone 7.1, если не ошибаюсь, но как-то не зашло. Блэнд, кстати, тоже не используется — все делает в Студии, напрямую в xaml'е.

Байдингам помогает ИнтеллиСенс, да и вью-модел ему доступен на просмотр.
Частенько, когда что-то по-сложнее, программисты ему накидывают прибайндженных контролей подряд во вью (например, в стакпанель, не заморачиваясь с тем, как это будет выглядеть в итоге), а дальше он уже сам их двигает-стилизует-анимирует.
Круто! Продвинутый у вам дизайнер.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий