net maui что это
.NET MAUI Toolkit не будет содержать функций MVVM из Xamarin Community Toolkit, таких как AsyncCommand. В дальнейшем мы будем добавлять все функции, специфичные для MVVM, в новый пакет NuGet, CommunityToolkit.MVVM.
.NET MAUI Markup Toolkit позволяет разработчикам продолжать создавать архитектуру своих приложений с использованием MVVM, привязок, словарей ресурсов и т.д. без необходимости использования XAML:
Расширения пользовательского интерфейса Fluent C#
Вот примеры из моего приложения HackerNews с открытым исходным кодом:
1. ContentPage
2. DataTemplate
Документация
Мы объединились с командой Microsoft Docs, чтобы найти новый дом для всей документации Community Toolkit. Следите за обновлениями в будущем, когда мы объявим о новом местоположении документов Community Toolkit на docs.microsoft.com.
Начало работы
CommunityToolkit.Maui
CommunityToolkit.Maui.Markup
В консоли диспетчера пакетов Visual Studio введите следующую команду:
Install-Package CommunityToolkit.Maui
или
Install-Package CommunityToolkit.Maui.Markup
Чтобы добавить пространство имен в инструментарий:
В C# добавьте следующее:
.NET Multi-platform App UI (.NET MAUI) is a cross-platform framework for creating native mobile and desktop apps with C# and XAML.
.NET Multi-platform App UI (.NET MAUI) is currently in preview. This content relates to a pre-release product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
.NET MAUI is for developers who want to:
.NET MAUI unifies Android, iOS, macOS, and Windows APIs into a single API that allows a write-once run-anywhere developer experience, while additionally providing deep access to every aspect of each native platform.
.NET MAUI apps can be written on PC or Mac, and compile into native app packages:
Building apps for iOS and macOS requires a Mac.
.NET MAUI essentials
.NET MAUI single project
.NET MAUI apps typically consist of a single project that can target Android, iOS, macOS, and Windows. This delivers the following benefits:
.NET hot reload
.NET MAUI includes support for XAML hot reload, which enables you to save your XAML files and see the changes reflected in your running app without recompilation. In addition, your navigation state and data will be maintained, enabling you to quickly iterate on your UI without losing your place in the app.
Создание первого приложения
поддержка Visual Studio для Mac будет приступить в будущем выпуске.
Предварительные требования
начало работы с Visual Studio 2022 17,1 (предварительная версия)
В окне Настройка нового проекта укажите имя проекта, выберите подходящее расположение и нажмите кнопку создать :
Дождитесь создания проекта и его зависимостей для восстановления:
В окне пакет SDK для Android принятия условий лицензии нажмите кнопку принять :
В диалоговом окне » контроль учетных записей пользователей » нажмите кнопку «Да «:
дождитесь, пока Visual Studio загрузит пакет SDK для Android и Android Emulator.
В диалоговом окне » контроль учетных записей пользователей » нажмите кнопку «Да «:
В окне новое устройство нажмите кнопку создать :
В окне принятие условий лицензии нажмите кнопку принять :
дождитесь Visual Studio скачайте, распакуйте и создайте эмулятор Android.
Закройте окно Android Device Manager :
Visual Studio запускает эмулятор Android, выполняет сборку приложения и развертывает приложение в эмуляторе.
В работающем приложении в эмуляторе Android нажмите кнопку «Click Me » несколько раз и обратите внимание на то, что число нажатий кнопок увеличивается.
WPF, UWP, WinUI, MAUI, Windows App SDK
Вот уже года 3 Microsoft проводит «рефакторинг» в своём «королевстве». Несколько устав видеть одни и те же споры в твиттере, и оставлять одни и те же комментарии на хабре, я решил расписать как же многочисленные UI-фреймворки MS соотносятся между собой. Кто из них больше мёртв. Возможно, кому-то это поможет в выборе технологии для будущего проекта.
Windows API и Windows Runtime
Прежде чем начать разбираться с UI-фреймворками стоит сначала опуститься на уровень ниже, впрочем, без особых подробностей. В современной винде 2 основных API для работы приложений. Windows API (обычно сокращается до Win32) и Windows Runtime (WinRT). При разработке первый был ориентирован на язык С, и активно развивался вплоть до выхода Windows 8. Я не имею в виду, что этот API объявлен устаревшим, но все новые функции системы уже разрабатывются для WinRT. Хотя некоторые так же бекпортируются и в Win32. Приложения, которые работают через Win32 и используют его модель приложений и сервисов Microsoft называет классическими.
Ключевое: есть объектно-ориентированные метаданные, которые описывают публичный интерфейс библиотеки: поддерживаются базовые классы (числа, строки), асинхронность (async/await), события. Начиная с Windows 8 весь новый API — это COM, с которым можно взаимодействовать через данный протокол. Любой язык, который реализует языковую проекцию в WinRT (C++/WinRT, Rust/WinRT, Python/WinRT, С#/WinRT) может взаимодействовать с этим API, будто это нативная для языка библиотека. Компоненты WinRT могут быть написаны на любом их этих языков. Сам виндовый API написан при этом на C++.
Помимо объектно-ориентированности, новый API имеет версионирование, больший контроль доступа к вызовам. Некоторые системные вызовы могут делать только приложения определённых разработчиков, некоторые доступны по специальному ключу. Некоторые сокрыты весьма условно: если приложение попало на комп, оно может ими пользоваться. Но вот в Microsoft Store могут и не пустить.
Application Models
Два вышеописанных системных API в данный момент подразумевают две разных модели жизненного цикла приложений. Классическая модель — приложению можно почти всё, оно может залезть почти куда угодно, читать что угодно, прятать окна и свою деятельность. С одной стороны — это позволяет делать различные удобные штуки вроде Punto Switcher, или сворачивание в трей по закрытию окна (вопреки ожиданиям, это не стандартное поведение в Windows). С другой стороны, это развязывает руки любым троянам.
И это было одной из причин, почему для приложений, работающих с WinRT, за основу была взята модель из мобильных платформ — изолированные приложения с контролируемым системой жизненным циклом. Другой из озвученных причин является большая энергоэффективность мобильного подхода. Всё же значительное количество ПК — ноутбуки. Вылилось это в повсеместные ограничения, привязку времени жизни приложения и времени жизни его основного окна (пока-пока сворачивание в трей). А также сильные ограничения работы в фоновом режиме. На размен давались различные фоновые задачи, контролируемые системой, и легальные способы интеграции в систему (системные контракты, такие как Share UI). В Microsoft посчитали, что за неполные 9 лет за счет таких интеграций появилось около 40 возможных точек входа в приложение. В какой-то момент даже появилась возможность делать консольные приложения, работающие поверх WinRT.
Стоит так же отметить, что эти две модели не изолируют Win32 и WinRT API друг от друга. В UWP приложения всё так же можно подключать Win32-библотеки, пока это не открывает путь за пределы песочницы. Из Win32 можно дергать WinRT API, но для большей его части надо получить AppIdentity, до недавнего времени это означало, что приложение придётся запаковать и оно станет чуть более изолированным.
И, пожалуй, именно тут надо вспомнить про UWP (Universal Windows Platform). Технически это название для реализации Windows Runtime в Windows 10+. Дело в том, что Windows Runtime в телефонах и Windows Runtime в Windows 8 отличались настолько, что для них нужно было делать отдельные сборки приложений (даже для одной архитектуры процессора). С появлением Windows 10, ОС и рантайм допилили до того состояния, когда 1 сборка приложения может запускаться и на телефоне (тогда они ещё были), и на ПК. Так же к этому списку добавились XBox, IoT, Hololens и Teams (большая интерактивная «маркерная доска»)
На практике, под сокращением UWP часто понимают именно UWP-приложения.
UI-фреймворки
Наконец можно поговорить про UI-фреймворки. С Windows Forms и WPF многие знакомы. UI, работающий поверх Win32 API. Отличаются способом верстки UI (дизайнер или XAML) и способом отрисовки (GDI или DirectX). С появлением WinRT, эти фреймворки особо не развиваются, но из-за огромного количества легаси приложений, Microsoft вынуждена поддерживать их. Например, в последних выпусках десятки значительно улучшена поддержка HDPI для WinForms.
WinUI
WinUI достоин отдельного упоминания, так как он един в двух лицах.
WinUI 2.x — UI-библиотека для UWP-приложений, содержащая в себе новые, в том числе экспериментальные, контролы. А также, обеспечивающая совместимость со старыми версиями Windows 10 (аналог AndroidX)
WinUI 3.x — часть Windows App SDK. Фактически это и есть UI-фреймворк для UWP, только оторванный от жизненного цикла UWP-приложений.
Обе версии сейчас развиваются параллельно.
Project Reunion он же Windows App SDK
Собственно, посмотрев на это обилие фреймворков (ещё и ввязавшись зачем-то в ReactNative), и выслушав жалобы разработчиков, в мае 2020 Microsoft анонсировала объединение подходов. Разработчики Windows Forms и WPF хотят писать стильные/модные/молодёжные приложения, получить доступ к новому API (в том числе различным системным триггерам, которые бывают довольно удобны). UWP-разработчики хотят получить больший доступ к системе и более простые способы распространения приложения, так как сейчас мимо стора распространять приложение не просто.
Собственно, WinUI 3.x является частью решения. Берём графический фреймворк от UWP-приложений, насаживаем его на жизненный цикл классических приложений. И все счастливы.
На самом деле, все конечно сложнее. И что за монстр Франкенштейна в итоге получится мы узнаем уже в конце года. Впрочем начать знакомиться можно уже сегодня.
Так жив ли больной?
UWP, как подсистема винды, никуда не денется в ближайшее время. Это всё ещё основной вектор развития API системы. Для UWP-приложений, которые нацелены только на десктоп, уже настало время планировать портирование на Windows App SDK. Недавно выпущенная версия 0.8 уже допускается в Microsoft Store. Если же приложение должно работать и на других платформах (Xbox, Hololens и т. д.), то тут придется ждать следующего года. Но рано или поздно, таки придется переехать на Windows App SDK.
Касательно классических приложений, покуда вам не нужны новые фичи платформы (пуши, возможность поделиться в ваше приложение, новый богатый UI и т. п.), то делать в общем-то тоже ничего не надо.
Если писать новое приложение, то стоит оценить Windows App SDK в текущем его состоянии. И возможно писать на нём.
А как же MAUI?
MAUI — абстракция над нативными UI-фреймворками.
Собственно, на винде это будет абстракцией над WinUI. У Xamarin.Forms есть поддерживаемая сообществом реализация поверх WPF.
Аналогичным образом ReactNative for Windows так же является абстракцией поверх WinUI. На нем, кстати, написан магазин на Xbox.
Подытожим
UWP — название подмножества API Windows, но часто используется как сокращение для изолированных приложений, работающих на этом API.
WinUI — современный графический фреймворк для Windows
Windows App SDK — в перспективе, единый набор SDK для любых приложений на Windows, вне зависимости от языка, и с возможностью переключения между различными жизненными циклами приложений
Настройка элементов управления с помощью обработчиков
Примеры
Обработчики обычно настраиваются для расширения внешнего вида и поведения собственного элемента управления платформой. Обработчики можно настроить для каждой платформы с помощью #ifdef директивы компилятора для многоцелевого кода на основе платформы. Тем не менее можно легко использовать папки или файлы, относящиеся к конкретной платформе, для организации такого кода.
Настройка обработчика может варьироваться от простого к сложному. Более сложные примеры будут отображаться во времени.
Настройка цвета фона для всех элементов управления
В следующем примере выполняется настройка цвета фона каждого элемента управления в приложении на устройстве Android на голубой:
Удалить подчеркивание ввода Android
В следующем примере подчеркивание удаляется из всех Entry элементов управления в приложении на Android:
Настройка конкретных экземпляров элементов управления
Обработчики для конкретных экземпляров элементов управления могут быть настроены с помощью подкласса элемента управления, а затем путем изменения обработчика для родительского элемента управления только в том случае, если элемент управления имеет тип подкласса. Например, чтобы настроить определенные Entry элементы управления на странице, содержащей несколько Entry элементов управления, сначала необходимо подклассировать Entry элемент управления:
Затем можно настроить EntryHandler для выполнения требуемого изменения MyEntry экземпляров.
Все MyEntry экземпляры будут настроены в соответствии с изменением обработчика.