uwp или wpf что выбрать

Uwp или wpf что выбрать

Пока UWP не изучал, хотелось бы подробнее погрузится. Бегло посмотрел сложилось впечатление что это продолжение WPF

1. те же объекты все очень похоже даже ощущение что достаточно взять WPF приложение и просто изменить тип
2. типизированные биндинги что можно считать как улучшение WPF
3. работает на всех устройствах Windows10 и я так понимаю и на десктопе начиная с Windows 7 тоже.

	От:	Globster
	Дата:	20.02.16 17:32
Оценка:	38 (1) +1

Строго говоря, это не совсем так. UWP это только Windows 10
Терминология у Микрософта несколько своеобразная, но есть быть точным, то
UWP базируется на WinRT (Windows Runtime), которое появилось в Windows 8, далее развилось в Windows 8.1
и Windows 10. Во времена 8 / 8.1 такие приложения назывались Windows 8 Universal apps

Приложения WinRT вы под Windows 7 писать не сможете, соответственно UWP там работать тоже не будет.

В UWP разработка возможна без использования XAML (и генерируемых из него объектов)
Например, с использованием Direct3D (я именно так и делаю).

WinRT имеет свою специфику. Это не десктопные приложения вообще. Хотя, конечно, они могут
запускаться в режиме десктопа (окно с «хромом», то есть с заголовком, рамкой и т.п. атрибутами)
В WinRT другая модель приложения, специфическая. Сам WinRT похож на COM (Component Object Model)

То, о чем вы говорите (в сравнении) относится к частному случаю, так называемым
C# XAML приложениям. Они да, похожи на WPF, но они частный случай UWP.

	От:	VTT	http://vtt.to
	Дата:	20.02.16 17:45
Оценка:	4 (1)

	От:	Vladek	Github
	Дата:	25.02.16 06:15
Оценка:	+2

Здравствуйте, okon, Вы писали:

O>Пока UWP не изучал, хотелось бы подробнее погрузится. Бегло посмотрел сложилось впечатление что это продолжение WPF

Нет, это подобие рантайма Silverlight со всеми его особенностями и ограничениями.

O>1. те же объекты все очень похоже даже ощущение что достаточно взять WPF приложение и просто изменить тип
Смотри выше.
O>2. типизированные биндинги что можно считать как улучшение WPF
O>3. работает на всех устройствах Windows10 и я так понимаю и на десктопе начиная с Windows 7 тоже.

WPF работает только на ПК, UWP на подходящих устройствах с Windows 10.

Источник

Перспективы технологий WPF и UWP, что выбрать?

Перспективы WPF
Есть ли сейчас смысл начинать изучать WPF? Будет ли эта технология востребована через год, два? Я.

Что выбрать для отрисовки графика в wpf?
Будут поступать данные с com порта. И нужно будет эти данные показать в виде кривой, которая через.

Что выбрать WPF, ZedGraph или MsChart?
Мне нужно построить диаграмму и 3-х мерный график в проекте для Windows. Пишу на C# Использую.

Привязка по расположению (margin) UWP, WPF
при изменении размера изменяется размер элемента. как правую сторону привязать к центру? Пример.

Решение

Empty_Boy, ещё жизненный цикл UWP приложения немного отличается от обычного десктопного приложения. То есть, свернёшь ты приложение, не факт, что оно будет работать в фоне (пользователь вообще может в настройках запретить твоей программе работать в фоне, или если на ноутбуке не подключено питание, то тоже не факт, что будет работать, что ты там не пиши). При старте винды, винда может подгрузить UWP приложения частично. Ты можешь, кстати, написать свою логику, которая отработает при подгрузке виндой в фоне твоей программы. Там много нюансов. В целом в UWP очень много всяких фишек, которых нет в WPF, особенно там всё хорошо с анимациями, которые работают в 60 FPS.

Обновляется приложение в фоне, ты даже можешь и не узнать, что оно обновилось (твоя программа у пользователя). Можешь настроить так, чтобы новая версия поставилась некоторому проценту пользователей, а не всем сразу.

Есть x:Bind, который работает быстрее, чем Binding и ты можешь даже посмотреть, какой код нагенерился для этих байндингов. Можно в XAML писать привязки сразу к методам, а не через команды (при том сигнатура метода не обязана совпадать с сигнатурой делегата (например, TypedEventHandler требует метод с двумя параметрами).

Если в WPF ты, вероятно, будешь строить всё на окнах, а не переходах по страницам, то в UWP всё основано на переходах и часто нужно будет после перехода выполнять какие-то действия.

Добавлено через 6 минут
Вот статья, почему Сбербанк выбрал UWP

Источник

О приложениях UWP для разработчиков WPF

Хотел бы закодировать разработчиков WPF от боязни чего-то нового, рассказав про отличия, которые ожидают их при разработке приложений под универсальную платформу Windows. Так что ставьте банки перед монитором, я начинаю давать установку.

Какие-то изменения в языках программирования и платформах происходят постоянно. Представьте себе на минуту, что выйдет C# версии 10 и все. Это последняя версия. Представили? Я представил. И в моем представлении если это и случится когда-нибудь, то эта последняя версия языка будет регулярно обновляться.

Были «чудесные» времена, когда у меня немного разбегались глаза от различий в коде (даже в коде XAML): WPF, Silverlight, Windows Phone, потом WinRT, а теперь еще и UWP. Сколько разработчиков никогда не путаются? Я думаю, что большинство разработчиков не держат все в памяти. Достаточно держать в памяти основные концепты работы. Когда дело касается кодирования, то используются вспомогательные инструменты вроде IntelliSense, Blend и т.п. Никуда не уйти и от использования сниппетов.

По каким причинам происходят изменения:

1. Где-то сидит вредный дядя, который ждет момента, когда все привыкнут к платформе/среде разработки. И тогда он что-то меняет.
2. Усовершенствования/новый функционал.
3. Отзывы пользователей или разработчиков (не понравилось и все тут). Исправление ошибок.
4. Аппаратная часть совершенствуется. Акцент на энергосбережение, на производительность или же на красивые эффекты.
5. Что-то глобальное. Например, последнее объединение платформ в UWP или что-то вроде «Мы хотим чтобы на C# писали под все платформы сразу, минуя Xamarin, поэтому добавили вам новые аналогичные другим платформам контролы». Кто знает, может через несколько лет будет и такое.
6. Ваш вариант напишите в комментариях.

Так что вполне можно начать знакомиться с новой платформой. Давайте я сделаю небольшой экскурс, описав некоторые отличия.

Начну с того, что приложения UWP обладают кое-чем, чего нет у классических приложений Windows – у них есть App Model. Что такое App Model? Это своеобразный регламент. Описание всех возможностей приложения — его прав доступа, способа установки, обновления, хранения информации и т.п.

У приложений Windows Store, точно так же как и у приложений UWP есть файл манифеста, в котором описаны все возможности и права приложения. Это файл Package.appxmanifest. Его можно редактировать как в графическом редакторе, так и в виде кода XML. Скриншот графического редактора смотрите ниже.

Элементы управления

Если вы помните, то совсем недавно у Windows 8 и 8.1 была Charm panel – волшебная панелька:

Сейчас же вместо нее используются более привычные для WPF разработчиков контролы:

Здесь новым контролом является ContentDialog, который блокирует приложение, примерно так же, как блокирует его MessageBox.
Кроме того в UWP более привычная для разработчиков WP навигация:

Что может показаться интересным, так это то, что некоторые элементы управления могут иметь различный внешний вид при отображении на различных устройствах. Простыми словами, контрол может выглядеть немного иначе, например, при отображении на десктопе и на мобильном устройстве.

В целом, я так полагаю, среднестатистический разработчик уже давно привык большому разнообразию контролов. Освоение новых трудностей вызвать не должно.

Разработка под различные устройства

Постараюсь разобрать то, что для WPF разработчика будет необычным. Например, это то, что при разработке приложений Windows 8.1 можно было в одном решении разрабатывать одновременно и под телефон и под десктоп.

В таком случае создавалось 3 проекта. В приложениях WP и WinRT хранился xaml код «вьюшек» и какой-то особый код под устройства, а в общем проекте хранился общий код xaml и общий для двух проектов код C#.

Сейчас же, так как платформа UWP универсальная, то для каждого типа устройств можно создать папку, в которую можно поместить «вьюшку» — т.е. xaml файл с дизайном под параметры устройства.

Жизненный цикл

Есть старая шутку про формулу-1: «У Ральфа Шумахера два положения педали – включено и выключено. Остальными положениями можно пренебречь».

Триггеры и фоновые задания

Что касается приложений 8.x и UWP, то они могут содержать в себе фоновые задания. Фоновые задания это некоторое подобие сервиса. То есть приложение может не работать, но в системе будет выполняться какая-то задача. Кроме того фоновая задача может «отлавливать» какие-то события в работе системы триггером.

Один из самых популярных триггеров это SystemTrigger. С помощью него приложение может выполнить какой-либо код при наступлении таких событий как: появление или пропажа интернета, изменение состояния сети, подключение или отключение пользователя, получение смс, изменение часовой зоны и т.п.

Также довольно популярны TimeTrigger и MaintenanceTrigger. Оба триггера выполняют какой-либо код с периодичностью в определенный промежуток времени. Промежуток времени должен быть не менее 15 минут. Отличие в то, что TimeTrigger требует регистрации приложения на экране блокировки, а MaintenanceTrigger-у требуется чтобы устройство работало не от батареи, а от сети.

В UWP появилось много новых триггеров. Взять, например такой вот интересный триггер как MediaProcessingTrigger, который позволяет приложению перекодировать мультимедиа в рамках фоновой задачи.

Использование библиотек

Если в классических приложениях вы использовали библиотеки DLL, то в приложениях 8.x и UWP вы сможете использовать как PCL, так и компонент среды выполнения WinMD. В чем отличие?

WinMD может быть использован только под 8.x или UWP. Вне зависимости от языка, на котором написаны приложения, они могут работать с WinMD. Но сам WinMD в случае если он содержит в себе сложные вычисления лучше писать на C++ для достижения наилучшей производительности.

Впрочем, при разработке под UWP вы можете создать и библиотеку классов (DLL).

Работа с данными

В чем еще заключается отличие приложений UWP, так это в том, что они не работают с базами данных напрямую. То есть такие базы данных, как, скажем SQL Server или Oracle, расположенные на сервере организации, будут вам недоступны. Впрочем, это было бы странно, если бы пользователь скачивал из Store приложение, и приложение начинало бы работать с базой SQL Server-а, расположенной на сервере в локальной сети. Но вы сможете работать с данными, используя веб-сервисы. Есть возможность использовать для баз MySQL оракловский Connector/Net, но он на данный момент не поддерживает SSL и потому не особо интересен. Так что лучше не отклоняться от концепта использования сервисов для доступа к данным.

Для хранения информации внутри приложения вы можете использовать SQLite.

Хранения параметров приложения и работа с файлами

Хранение параметров приложения возможно не только на устройстве, но и в облаке. Таким образом, если запускать приложение на различных устройствах, то настройки везде будут одинаковыми.

Следующий небольшой сниппет сохраняет количество вызова кода в облаке:

Если заменить Windows.Storage.ApplicationData.Current.RoamingSettings на Windows.Storage.ApplicationData.Current.LocalSettings, то параметр будет сохранен локально на устройстве.

Настройки могут быть скомпонованы как в составные параметры, так и в контейнеры. Файлы точно так же как и настройки можно хранить как на устройстве в локальной папке, так и в облаке. Но кроме этого есть возможность хранить файлы во временной папке, которая при необходимости может быть очищена системой — ApplicationData.TemporaryFolder.

Кроме того можно получить доступ к папке, которая содержится в приложении с помощью
Windows.ApplicationModel.Package.Current.InstalledLocation

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

Получить после этого последнюю сохраненную папку можно так:

Привязки данных

Как в приложениях WPF, так и в приложениях UWP, а также при разработке под 8.x можно использовать привязки данных – . Но в UWP появились еще и компилируемые привязки – В чем отличие? Компилируемые работаю гораздо быстрее, а формируются/проверяются они во время компиляции а не во время запуска приложения. Также они строго типизированные.

Эффективные пиксели

Создавая приложение UWP, вы ведете разработку в эффективных пикселях, а не физических. Особый алгоритм масштабирования позволяет добиться того, что шрифт размера в 24 пикселя будет одинаково читаемым и на большом экране PC и на экране телефона.

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

Пример: если вы заходите создать вариант изображения для устройств с коэффициентом масштабирования 150, то вам нужно создать изображение размера 66×66 и назвать его Square44x44Logo.scale-150.png.

Это касается не только изображений, используемых в описании приложения, но и изображений, которые вы используете в UI.

Источник

Причины использования современных классических приложений

Введение

История одной компании

Ваша история

Классические приложения в наше время

До эпохи Интернета классические приложения для настольных ПК были основным подходом к созданию программных систем. Разработчики могли выбрать любой язык программирования, например COBOL, Fortran, VB6 или C++. Но разрабатывали ли они небольшие средства или сложные распределенные архитектуры, — все это были приложения для настольных ПК.

Затем технологии Интернета начали перекраивать весь мир разработки и притягивать все больше разработчиков за счет таких преимуществ, как простое развертывание и упрощенные процессы распространения. Тот факт, что после развертывания веб-приложения в рабочей среде все пользователи получали автоматические обновления, оказал огромное влияние на гибкость программного обеспечения.

Однако инфраструктура Интернета, базовые протоколы и стандарты, такие как HTTP и HTML, не предназначены для создания сложных приложений. В реальности усилия разработчиков были тогда направлены на одну цель: предоставить веб-приложениям те же возможности, что и классическим приложениям, включая быстрый ввод данных и управление состоянием.

Несмотря на невероятные темпы роста веб-приложений и мобильных приложений, для некоторых задач классические приложения по-прежнему остаются на первом месте с точки зрения эффективности и производительности. Это объясняет, почему существуют миллионы разработчиков, создающих проекты с помощью WPF и WinForms, и объем создаваемых ими приложений постоянно растет.

Ниже приведены некоторые причины для выбора разработки классических приложений для настольных ПК:

Как видите, разработка для настольных систем — отличное решение по многим причинам. Технология проверена временем, а цикл разработки быстр. Отладка эффективна, и, возможно, настольные приложения проще, так что работу с ними легче начать.

С течением времени корпорация Майкрософт предложила многие технологии пользовательского интерфейса для настольных систем, от Win32, представленной в 1995 г., до универсальной платформы Windows (UWP), выпущенной в 2016 г.

В соответствии с опросом, опубликованным Telerik в апреле 2016 г., наиболее популярными технологиями для создания классических приложений Windows являются Windows Forms, WPF и UWP.

Вы можете вести разработку и там, и там, используя C# и Visual Basic, но давайте рассмотрим это поближе.

Windows Forms

Впервые выпущенная в 2002 году, Windows Forms является управляемой платформой и самой старой, наиболее часто используемой технологией для настольных программ, основанной на подсистеме интерфейса графических устройств Windows (GDI). Она предлагает гладкое перетаскивание для разработки пользовательских интерфейсов в Visual Studio. В то же время Windows Forms полагается на конструктор Visual Studio в качестве основного способа разработки пользовательского интерфейса, поэтому создание визуальных компонентов из кода в ней нетривиально.

В следующем списке перечислены основные характеристики Windows Forms:

Основываясь на спецификации языка XAML, WPF отдает предпочтение четкому разделению между пользовательским интерфейсом и кодом. XAML предлагает такие возможности, как создание шаблонов, стилей и привязок, которые подходят для создания больших приложений. Как и Windows Forms, это управляемая платформа, но проекты здесь модульные и пригодные для многократного использования.

Вот основные особенности WPF.

UWP — это не только платформа представления, такая как WPF и Windows Forms, но и сама платформа. Эта платформа содержит:

Эта платформа была создана для поддержки всех типов систем ввода (например, рукописного ввода, сенсорного экрана, джойстика, мыши, клавиатуры, взгляда и т. д.) во всех форм-факторах с учетом производительности и низкого энергопотребления. По этим причинам оболочка ОС Windows 10 использует части платформы UWP.

UWP содержит платформу представления, основанную на XAML, похожую на WPF, но имеющую некоторые важные отличия, такие как:

История двух платформ

В течение последних 20 лет, в то время как технологии пользовательского интерфейса для настольных систем совершенствовались на их пути от Windows Forms к UWP, оборудование также развивалось от тяжелых системных блоков с небольшими ЭЛТ-мониторами до мониторов с высоким разрешением и легких планшетов и телефонов с различными методами ввода данных, такими как сенсорный экран и рукописный ввод. Эти изменения привели к созданию двух различных концепций: классического приложения и современного приложения. Современное приложение — это программа, которая учитывает различные форм-факторы устройств, разнообразные методы ввода-вывода и использует современные функции настольных систем при работе в изолированной модели выполнения. Классическое приложение (оно же приложение для настольных систем), с другой стороны, является приложением, которому необходим надежный интерфейс пользователя с высокой плотностью элементов управления, который лучше использовать с мышью и клавиатурой.

В следующей таблице показаны различия между этими двумя концепциями:

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

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

Перенос функций современных приложений в классические приложения. В случае классических приложений, которым требуется способ использования современных возможностей без создания приложения с нуля, функции современных приложений помещаются в классическое приложение.

В этой книге мы сосредоточимся на втором и покажем, как можно модернизировать существующие классические приложения.

Пути к модернизации

Структура этого руководства содержит три различные оси для выполнения модернизации: современные функции, развертывание и установка.

Современные функции

Предположим, у вас есть рабочее приложение Windows Forms, используемое торговыми представителями компании для заполнения заказа клиента. Новое требование состоит в том, чтобы позволить клиенту подписывать заказ с помощью пера планшета. Рукописный ввод встроен в современные операционные системы и технологии, но он был недоступен при разработке приложения.

Этот путь покажет вам, как можно использовать современные функции для настольных систем в существующих разработках для настольных систем.

Развертывание

Установка

Настольные приложения всегда полагаются на процесс установки, прежде чем пользователь сможет приступить к их использованию. Этот факт позволяет использовать набор технологий, от MSI и ClickOnce до пользовательских установщиков или даже развертывания с помощью XCOPY. Все эти методы сталкиваются с проблемами, требующими аккуратности, так как приложениям требуется способ доступа к общим ресурсам на компьютере. Иногда установке требуется доступ к реестру для вставки или обновления новых значений ключей, иногда для обновления общих библиотек DLL, на которые ссылается основное приложение. Такое поведение создает непрерывную головную боль для пользователей и порождает впечатление, что после установки какого-либо приложения компьютер уже не вернется в исходное состояние, даже если потом его удалить.

В этой книге мы представим новый способ установки приложений с помощью MSIX, который решает проблему, описанную выше. Вы узнаете, как можно без труда настроить упаковку, установку и обновления для приложения.

Источник