После долгих лет неразберихи разработка Windows скоро улучшится ... медленно

Иногда быть разработчиком Microsoft кажется старой шуткой Марка Твена о погоде. Вы знаете одно - если вам не нравится API, который вам дали сегодня, подождите неделю и попробуйте следующий.

Мой любимый пример постоянного переосмысления Microsoft - это API баз данных в конце 1990-х, когда они выпустили алфавитный суп из различных трехбуквенных технологий (RDS, DAO, ADO, OLE DB). Но за прошедшее десятилетие никто не пострадал больше, чем бизнес-разработчики, пытающиеся писать графические приложения для Windows.

Два десятилетия приложений Windows

Когда .NET 1.0 впервые появился на сцене, жизнь была простой. Если вы были .NET-разработчиком, который хотел создать настольное приложение для Windows, вы использовали Windows Forms. Это было легко (почти как VB по простоте перетаскивания) и относительно полнофункционально. Да, вам может потребоваться обойти странное ограничение и время от времени вызывать Win32 API. Но если вам нужно простое бизнес-приложение, которое выглядело бы респектабельно и не требовало специального хромирования, мир был хорошим местом.

Затем дело пошло по-другому. Microsoft знала, что им никогда не удастся постепенно преодолеть ограничения, заложенные в Windows Forms, такие как плохая поддержка дисплеев с высоким разрешением и низкая производительность при настраиваемом рендеринге. Не было встроенного способа делать 3D, анимацию, частичную прозрачность (спасибо, Vista) или что-то еще, что в то время считалось передовым пользовательским интерфейсом. Поэтому Microsoft запустила масштабный проект переосмысления под названием WPF (Windows Presentation Framework).

WPF изменил практически все, от способа определения окон (теперь декларативно с использованием XML-грамматики под названием XAML) до аппаратной основы (DirectX, та же технология, которая поддерживает высокопроизводительные игры). Новые возможности WPF были достаточно впечатляющими, чтобы удержать программистов на борту, хотя некоторые изменения были болезненными. Например, в первом выпуске WPF не было возможности перетащить базовое окно в существование - функция, которая существовала в мире Microsoft со времен первой версии Visual Basic.

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

Все изменилось с кризисом идентичности Microsoft в 2010 году. Компания решила, что нужно пойти в совершенно другом направлении и конкурировать с новым набором конкурентов. Ему нужен был безопасный и безболезненный Microsoft Store для установки приложений, как на iPad и iPhone. Ему нужна была изолированная среда, чтобы она могла конкурировать с одностраничными веб-приложениями, написанными на JavaScript. Ему нужна была новая операционная система с десятком различных редакций, чтобы она могла поддерживать мобильные устройства с низким энергопотреблением (такие как планшеты, Surface RT и почти забытый Windows Phone). Решением всей этой паранойи стала еще одна среда разработки Windows, названная UWP (универсальная платформа Windows), также известная - в первые дни своего существования - как Metro.

Проблема заключалась в том, что UWP нельзя было назвать универсальным. Да, он работал на разных типах устройств Windows 10, в отличие от WinForms или WPF, но не поддерживал никакие предыдущие версии Windows. Этого единственного факта было достаточно, чтобы отговорить признанных разработчиков от перехода на UWP. Даже если они не нуждались в функциях полноценного настольного приложения, написанного на чем-то вроде WPF, они не хотели замыкаться в маленькой коробке компьютерной совместимости.

UWP не смогла заменить ни один из предшествующих наборов инструментов для настольных ПК. В сочетании с провалом других частей грандиозного видения Microsoft - мертвого Windows Phone, сокращающегося Microsoft Store, нестабильной мобильной операционной системы Windows RT - ценностное предложение UWP продолжало сокращаться. Дело не в том, что UWP была плохой технологией, просто она, несмотря на все свои компромиссы, решала проблемы очень немногих людей. В конце концов, если вы хотели создать современное изолированное приложение с нуля, почему бы не рассмотреть возможность использования JavaScript в браузере?

Это подводит нас к сегодняшнему состоянию разработки Windows. Все три фреймворка для настольных приложений Windows по-прежнему сосуществуют, занимая несколько разные ниши. Кроме того, разработчики по-прежнему поддерживают приложения C ++, построенные на MFC и Win32 API.

Войти в Project Reunion

Какое-то время казалось, что Microsoft просто дожидалась эры настольных компьютеров, надеясь, что ее лояльные разработчики в конечном итоге обменяют свои оконные приложения на веб-фреймворк, такой как Blazor. Но на конференции Build в этом году Microsoft отдернула занавес перед новой стратегией постепенной гармонизации различных моделей настольных компьютеров. Это путешествие начинается с чего-то, что называется Project Reunion.

Project Reunion - это шаг к разделению и совместному использованию частей пользовательского интерфейса UWP. Другими словами, Microsoft отделяет инструментарий пользовательского интерфейса от UWP (называемого WinUI 3), чтобы его можно было использовать в других типах приложений. Да, вы по-прежнему можете использовать WinUI для создания приложений UWP, которые по-прежнему работают в изолированной среде (даже если их не нужно развертывать через все более отстраненный магазин Windows). Но, что более важно, вы также можете использовать набор инструментов WinUI в других типах приложений. Фактически, вы можете использовать его со всеми фреймворками приложений Windows, над созданием которых Microsoft потратила последние два десятилетия, от устаревших приложений MFC до WinForms и WPF.

Это ценно, потому что WinUI включает элементы управления для создания пользовательских интерфейсов Fluent - веб-стиль дизайна, который помогает создавать современные красивые интерфейсы. Тонкие границы, переходная анимация и перекомпоновка макетов - вот некоторые из отличительных черт пользовательского интерфейса Fluent.

Если вы последние несколько лет игнорировали Fluent UI, потому что он также имел кучу лишнего багажа - например, Windows Store и изолированную среду - вам больше не нужно платить этот налог. Теперь вы можете создать настольное приложение .NET 5 с полной поддержкой оборудования, которое использует библиотеку WinUI.

Однако здесь есть одна загвоздка. Как и UWP, WinUI требует Windows 10. Похоже, это исключает ее для большого количества разработчиков, все еще поддерживающих ископаемые бизнес-среды - но, может быть, и нет. Это связано с тем, что Microsoft планирует расширить совместимость с WinUI до Windows 8.1. И это не просто призрачная надежда. Microsoft требуется совместимость с Windows 8.1 для поддержки проекта Windows React Native, который также использует WinUI.

WinUI сегодня

Большие вопросы очевидны. Как вы можете перенести приложение WPF или WinForms на WinUI? А ты должен?

Несмотря на то, что WinUI совместим со старыми типами настольных приложений, его модель пользовательского интерфейса отличается. Есть совместимость, но не гармония. Один из способов миграции - провести рефакторинг как можно большего количества кода из вашего пользовательского интерфейса, а затем внедрить новый скин, созданный с помощью WinUI. Другой вариант - пойти по частям. Одно приложение может комбинировать окна, использующие WinUI, с окнами, использующими WinForms или WPF, используя технику, называемую островами XAML. Это дает вам возможность медленно двигаться в будущее (но это также гарантирует, что ваше приложение будет иметь несколько шизофренический визуальный стиль, смешивающий воедино старую моду и новую). В любом случае Microsoft обещает надежную поддержку IDE. Например, вы не только сможете легко добавлять представления WinUI в проект WinForms или WPF, но также сможете использовать шаблоны проектов, сочетающие воедино различные фреймворки пользовательского интерфейса.

Следующий вопрос очевиден - он готов?

Сегодня WinUI 3 существует в общедоступной превью-версии. Этого достаточно, чтобы начать играть или даже планировать следующий выпуск. Но он не готов к производству. Планируемые функции, такие как поддержка Xbox и HoloLens, по-прежнему отсутствуют. Финальный релиз WinUI 3 назначен на ноябрь, одновременно с .NET 5.

Еще неизвестно, станет ли WinUI 3 слишком поздно. После частичного отказа UWP многие разработчики настольных компьютеров перешли к созданию настольных приложений с использованием веб-технологий, таких как Electron. Но для тех, кому нужно оставаться в мире настольных компьютеров Windows, путь в будущее выглядит более многообещающим, чем когда-либо. В переполненный мир настольных API-интерфейсов Sanity вернулась. И следующий шаг вперед - это не еще один совершенно новый фреймворк, а попытка воссоединить то, что у нас уже есть.

Чтобы получать рассылку раз в месяц с нашими лучшими техническими историями, подпишитесь на Информационный бюллетень Young Coder.