Comments 22
Я обожаю flutter и декларативный подход к ui
Один файл локализации на проект обычно удобнее для переводчиков (которые загружают весь файл в систему перевода, смотрят дифф и корректируют автоперевод).
В нескольких проектах приходилось специально писать тулинг для объединения нескольких файлов с локализациями (два фронта, бэкы, конфигурация) в один файл для переводчиков.
Также в Dart кодогенерация работает через build runner, что совсем пока не сравнится с теми же Incremental Source Generators в C#, когда код генерируется мгновенно при написании конкретных атрибутов, от которых зависит, где и каким образом будет генерироваться код.
Появились макросы https://dart.dev/language/macros
Можно рассмотреть slang, который позволяет разделить переводы на несколько файлов, используя namespace. Также там весьма годный консольный тулинг для работы с переводами.
В итоге настолько проникся удобством slang, что сделал порт библиотеки на .NET, чтобы не страдать при разработке десктопа и переводить через GPT
Удобство разработки определяется фреймворком в большей степени, а флаттер в разы проще и удобнее того, что есть в нативе и тем более проще чем Котлин мультиплатформ.
Чисто из любопытства и только что, попробовал Авалонию на Линукс. Десктоп proof of concept получилось, хоть и не без глюков, а темплет кросс-платформенного приложения тупо битый - проект не видит ни Avalonia ни Avalonoa.Android. Если в csproj файлах поменять Version="$(AvaloniaVersion)" на Version="11.0.10", то в некоторых местах гачинает видеть, но не во всех.
Мне тоже нравилась платформа .NET, но я отношусь к грязи как к крысам - если днём замечена одна, значит рядом сто тысяч...
Можно чуть подробнее, декларативный UI это что? Аля html с data binding (как в angular) или о чём речь?
Небольшой дисклеймер: употребляя ниже термин «декларативный UI», я имею в виду исключительно подходы Compose, Flutter и SwiftUI к построению интерфейса.
Все три работают примерно так - в виде кода описывается иерархия из виджетов(контролов), и эта иерархия из виджетов меняется при смене состояния. Это если грубо-говоря. HTML c биндингами в моем понимании - это не «декларативный UI».
За основу был взят фреймворк MvvmCross – единственный фреймворк на рынке, позволяющий использовать разделяемый UI под каждую из платформ.
Почему единственный, как на счёт ReactiveUI? Я его для Native Android и iOS использую.
Проблемы с дженериками на Android. Из этого, например, у нас на проекте было правило – не использовать их для Activity, View и Fragment.
А что именно имеется ввиду? У меня в проекте есть дженерик фрагменты, проблем не встречал, по крайней мере пока что.
На счёт неудобного тулинга при верстке согласен. Лично я из-за этого верстаю в Android Studio / Xcode.
Да, действительно, есть еще ReactiveUI - возможно, используя этот фреймворк, было бы меньше проблем, связанных с MvvmCross.
Насчет дженериков - была проблема, что иногда приложение просто крашилось с java исключением на уровне связывания .net View с java View. Я уже точно не помню какое именно исключение, загуглить тоже не получается, но проблема точно была. Возможно, это касалось только Activity.
Прошло более полугода с момента закрытия проекта на замарине и уже все напрочь забыл))
Начну с того, что в разрезе перехода с C# меня до сих пор смущает система импортов.
Хорошо, что в C# система импортов работает без нареканий)
В дарте и named импорты как в питоне есть, и можно с помощью show что-то конкретное импортировать.
Попробуйте в C# подключить либы с одинаковым неймспейсом, ZXIng и системный пакет с битмапой, например. А никак, их просто нельзя в одном проекте использовать.
Причем C# мне нравится гораздо больше, чем тот же Swift. Поэтому для разработки исключительно под iOS я бы посоветовал рассмотреть вариант использования .NET-iOS, если к Swift вы относитесь с предубеждением.
Kotlin и Swift - одного поля ягоды. Кто-то говорит, что Java лучше Kotlin - на котлине он не писал. Swift создан для создания приложений и справляется с этим лучше C#, т.к. менее громоздкий, более красивый и т.д..
Вот если бы у флаттера был котлин, то это был бы best framework ever made. Т.к. удобнее котлина я ничего в жизни не встречал.
Вообще, меня смущает наличие ';' в дарте. Во флаттер куча коллбэков и точка с запятой всегда неудобна.
Попробуйте в C# подключить либы с одинаковым неймспейсом, ZXIng и системный пакет с битмапой, например. А никак, их просто нельзя в одном проекте использовать.
Вообще-то можно, используя extern alias, легко загуглить. Эта возможность была добавлена ещё в C# 2.
Интуиция подсказывает, что MAUI закончится через год-два, как Silverlight, WSA, UWP, VS for Mac 2022
Смелое утверждение, но нет, не закончится.
Silverlight - умер потому что в браузерах убрали возможность встраивания, как и Flash, Java и др..
UWP - потому что были универсальные приложения запускаемые на WinPhone. Нету телефонов, не нужен и UWP.
VS for Mac - потому что появился VSCode с отличной поддержкой C#, не удивлюсь если VS for Win постигнет та же судьба.
WSA - эксперимент работавший всего в одном регионе и с одним магазином, эксперимент не оправдался.
Так что утверждения что MAUI умрет через год-два вызваны лишь личным хейтом, никаких предпосылок к этому нет. Все эти изменения были естественным эволюционным движением. Технология развивается.
У меня нет хейта к MAUI и microsoft. Я считаю просто, что на MAUI будет минимум production проектов на рынке, технология останется нишевой. Если бы MAUI поддерживал декларативный подход к построению UI, я бы по другому оценил шансы того, что технология не умрет.
Для MAUI есть C# Markup - можно как и во Flutter создавать представление через код. А вот Авалония поддерживает только очень своеборазные решения через F#.
Просто создавать из кода разметку недостаточно, чтобы это стало декларативным UI как во Flutter. Тут нужен совершенно другой подход к рендерингу, и возможно даже к самой платформе .NET. Например, сборщик мусора, оптимизированный под декларативный подход к UI. С такой проблемой, к примеру, столкнулись разработчики Jetpack Compose, сделав новый GC под их нужды, чтобы не было подвисаний и тормозов.
А что не попробовали react native? Такая же кроссплатформа, плюс все плюшки фронтендеров
ну не надо обманывать людей, не такая же
Ответ в статье от моего коллеги - то из чего выбирали и почему выбрали flutter)
Первый взгляд на переход с Xamarin Native на Flutter