Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, karbofos42, Вы писали:
K>>Ну, и непонятно тогда уж зачем нужно Uno, когда есть Avalonia
S>А разве Avalonia умеет в Android/iOS?
Не знаю как сейчас, а в 2018-м все это работало только на словах и в демонстрационных проектах. Реальное приложение (Kaspersky Who calls) написанное на Xamarin не АОТилось по дум причинам:
1. Баги вызываемые АОТ.
2. Увеличение размеров бинарей.
Думаю, что и сейчас ничего не изменилось.
А самое смешное, что лично мне пришлось признать бессмысленность и неприемлемость использования Xamarin для подобного приложения. Гуя там не много. Основной код — это логика перехвата и анализа звонков. Важно было знать АПИ. Причем код должен жить годами без перезагрузки (как системный сервис). Естественно в коде были ошибки. Например фризы. В Андроиде они называются ANR. Так вот к нам приходили отчеты об этих ANR. С ними были колстеки. Но в этих колстеках не было дотнентного кода. Там были только сишные колстеки ждущие каких-то кишек VM. Учитыая, что ANR-появлялись через 2 недели, а публикации новых версий были не частыми, на поиск проблем перебором мог уйти код. В итоге мы решили переписать это дело на Яве, так как это для нее в ANR-ах приходят нормальные колстеки. Плюсь это радной АПИ для платформы, а значит меньший размер бинарей. Ява как язык откровенное говно после Шарпа. Но преимущество родной платформы является определяющим.
В десктопной версии тоже Xamarin не используется. Так что это весьма специфичное АПИ. Полезно для тех кто делает фронтэнды с богатым гуем к разным серверам. В остальных случаях — не нужен. Если бы его реализовали путем переписывания в Яву мог бы получиться убер-продукт. Но в таком виде (со своей ВМ) — спорное решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
S>И смотришь скорость. У мненя вроде быстрее стал запускаться
Я разрабатывал с помощью Xamarin.Формы (будут переименованы в MAUI) на 5+ лет и платформа Uno в течение четырех месяцев. Есть ряд отличий, которые, на мой взгляд, стоили того, чтобы я потратил время на переход с Xamarin.Бланки в ООН. Во-первых, сходство:
Оба являются кроссплатформенными фреймворками C#
Оба имеют поддержку XAML
Оба поддерживают iOS, Android, универсальную платформу Windows и (в меньшей степени) Mac OS через не -.Формирует фреймворки платформы Xamarin.
Ксамарин.Essentials работает как с Xamarin, так и с Uno на вышеуказанных платформах
Ни один из них не имеет встроенной поддержки печати, создания PDF или PNG.
Теперь о различиях:
Архитектурно, Xamarin.Формы-это собственный уровень абстракции над собственными API, где as Uno создает интерфейсы UWP на основе собственных API. Это, на мой взгляд, самое важное различие по трем причинам:
В Android, Xamarin.Абстракция форм включает в себя управление измерениями и компоновкой. Это ОЧЕНЬ ДОРОГО и для всех видов списков, кроме самых простых, приводит к очень низкой производительности. Uno, напротив, выполняет это на собственном уровне — таким образом, избегая большого количества переходов между Java и C#.
В WASM Xamarin визуализируется с помощью Blazor, что позволяет использовать гибридные серверные / клиентские приложения. К сожалению, это добавляет сложности по сравнению с подходом, применяемым ООН. Еще предстоит выяснить, приводит ли подход Xamarin к снижению производительности.
Поскольку Uno строит UWP на основе собственных фреймворков пользовательского интерфейса, довольно просто открыть обложки и внести глубокие изменения в функции. Это гораздо сложнее (если не невозможно в некоторых случаях) сделать в Xamarin.Формы.
Uno имеет сильную поддержку WPF (так что да, он может работать в Windows 7), Tizen и Linux (GTK).
Uno поддерживает сложность XAML UWP, которая, если у вас есть опыт работы с WPF или UWP, имеет некоторые основные преимущества. В противном случае это будет потеряно для вас, как и для меня. Я надеюсь это изменить.
Uno поддерживает библиотеки WinUI и Windows Community Toolkit.
Хотя я не могу быть в этом уверен, я верю Xamarin.Формы существуют примерно на 2-3 года дольше, чем платформа Uno. Тем не менее, Uno быстро догнала Xamarin по функциям и качеству кода. Я считаю, что это отчасти связано с тем, что UWP является очень зрелой операционной спецификацией.
По моему опыту миграции проекта из ~132 тыс. строк Xamarin.Формирует код для Uno, Uno был значительно менее подробным, в ~65 тыс. строк. Почти все это сокращение произошло в строках кода пользовательского интерфейса (модели, модели представлений и бизнес-логика были почти нетронуты). Во многом это было связано с тем, насколько более многофункциональными могут быть элементы управления UWP (Uno).
Наконец, вы спросили, может ли ваша программа WPF работать в Linux с помощью этих двух технологий. Ответ таков:
Xamarin.Формы: Нет. Linux не поддерживается;
Платформа Uno: Нет, но вы можете перенести свой код. Усилия будут примерно такими же, как при переносе вашей программы из WPF в UWP.
Ваш пробег может отличаться. Однако, если у вас есть опыт работы с WPF или UWP, я бы настоятельно рекомендовал Uno. Если у вас нет опыта работы ни с тем, ни с другим, то я бы рекомендовал Uno из-за превосходной производительности с Android.
Ну они сейчас развивают PGO. То есть не полностью AOT, а только часто используемые блоки.
При этом Jit рефлексия и динамическая компиляция сохраняется. То же и в Андроиде. Announcing .NET 6 Release Candidate 1
Что касается Замарин, то это прежде всего использование единого кроссплатформенного кода.
Код един, а вот что касается гуя то уж тут на выбор либо Xamarin.Forms либо нативный для каждой платформы. Ну вот и MAUI подошел.
При этом этот же код можно использовать и для Блазора.
Ну всегда можно обернуть явовские и котлиновские библиотеки через биндинг
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, karbofos42, Вы писали:
K>>Функциональный стиль — это новый паттерн MVU, который я себе пока слабо представляю в реальной жизни.
vaa>Вот чувачок замиксовал F# + XAML(C#) вроде норм. надо сравнить перфоманс
vaa>https://github.com/xperiandri/Elmish.Uno
Тебе нужно отдельную ветку про новости UNO открыть!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Всегда можно было. Тот же Xamarin.Forms в начале был без Xaml редактора
VD>А кто про редактор то говорил?
Потому и Xaml не было. Все в коде писали.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>>Потому и Xaml не было. Все в коде писали.
VD>Так причем тут редактор? Без него можно код править?
Xaml? В начале в .Net Core и прочим была выпилена работа с XML. https://docs.microsoft.com/ru-ru/xamarin/xamarin-forms/xaml/xaml-basics/
КОД XAML никогда не нужен в Xamarin.Forms программе, но часто является более сжатым и более наглядным, чем эквивалентный код
Ответ был дан на это высказывание.
нет. теперь UI компонент можно писать в функциональном стиле на C# как в реакте и без XAML, тут в форуме кидали ссылку на анонс на devblogs microsoft с примерами. Оно будет как то взаимодействовать с тем что уже написано на XAML
Другое дело, мне например в котлине нравится построение DSL . Возможно с использование Source Generator можно использовать различные конструкции для упрощения кода
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vaa, Вы писали:
vaa>Кто-то знает почему и зачем MAUI, если есть UNO?
Ну наверное MAUI это Xamarin.Forms, а UNO это новый продукт, не совместимый с Xamarin.Forms.
Думаю новые проекты будут на UNO
и солнце б утром не вставало, когда бы не было меня