У Flutter есть целая страница, посвященная привлечению людей из Xamarin.Forms. Вы говорите, что мы должны игнорировать конкуренцию. Действительно?

Крепления Blazor красивы! Я только начинаю с них, и они предлагают ту же простоту, что и Flutter.

@davidortinau, как я сказал в другой ветке. Сообщение в блоге MAUI вызвало огромную путаницу. Люди теперь, кажется, думают, что MVU = view as code / DSL.
Но это совершенно не зависит от того, что такое МВУ. MVU вполне возможен с XAML. Это не имеет ничего общего с тем, как вы пишете представление.
Речь идет только о создании неизменяемой модели + функции обновления, которая принимает модель и сообщение и строит новую модель, а также функцию просмотра, которая не изменяет модель напрямую, а отправляет новые команды (сообщения) в цикл обновления.

Я думаю, что MAUI должен придерживаться только одного способа разработки пользовательского интерфейса, а именно: XAML.

Blazor Syntex в порядке, но MVU мне кажется совершенно ненужным беспорядком. Если это нужно для привлечения разработчиков Flutter, пожалуйста, позвольте им остаться с Flutter; НЕ разрушайте красоту XAML;

Он предназначен для разработчиков C # и .NET.

@ sim756

Я думаю, что MAUI должен придерживаться только одного способа разработки пользовательского интерфейса, а именно: XAML.

Никогда не было только одного пути. Пользовательские интерфейсы на основе кода поддерживались через Xamarin.Forms с самого начала. Имеет смысл сделать это более доступным. Кстати: MVU можно легко использовать с XAML ( Xamarin.Forms , WPF ).

@ Happypig375

У Flutter есть целая страница, посвященная привлечению людей из Xamarin.Forms. Вы говорите, что мы должны игнорировать конкуренцию. Действительно?

Что ж, нам лучше иметь страницу " Xamarin для разработчиков Flutter "!

@rohanbojja

Крепления Blazor красивы! Я только начинаю с них, и они предлагают ту же простоту, что и Flutter.

Все в порядке, кроме этого, и именно поэтому я не люблю Flutter :

Изображение 0

@forki

@davidortinau, как я сказал в другой ветке. Сообщение в блоге MAUI вызвало огромную путаницу. Люди теперь, кажется, думают, что MVU = view as code / DSL.
Но это совершенно не зависит от того, что такое МВУ. MVU вполне возможен с XAML. Это не имеет ничего общего с тем, как вы пишете представление.
Речь идет только о создании неизменяемой модели + функции обновления, которая принимает модель и сообщение и строит новую модель, а также функцию просмотра, которая не изменяет модель напрямую, а отправляет новые команды (сообщения) в цикл обновления.

Я действительно запуталась !! Спасибо, вы только что дали понять, пост катастрофически запутанный:

Изображение 1

@ saint4eva

Я думаю, что MAUI должен придерживаться только одного способа разработки пользовательского интерфейса, а именно: XAML.
Blazor Syntex в порядке, но MVU мне кажется совершенно ненужным беспорядком. Если это нужно для привлечения разработчиков Flutter, пожалуйста, позвольте им остаться с Flutter; НЕ разрушайте красоту XAML;

Он предназначен для разработчиков C # и .NET.

" Он предназначен для разработчиков C # и .NET. "

@aspnetde

@ sim756

Я думаю, что MAUI должен придерживаться только одного способа разработки пользовательского интерфейса, а именно: XAML.

Никогда не было только одного пути. Пользовательские интерфейсы на основе кода поддерживались через Xamarin.Forms с самого начала. Имеет смысл сделать это более доступным. Кстати: MVU можно легко использовать с XAML ( Xamarin.Forms , WPF ).

Я знаю. Иногда мы пишем new Button() { .... } , но этот пост ( Изображение 1 ) сбил меня с толку и, как мне кажется, многих других.

@ Happypig375

У Flutter есть целая страница, посвященная привлечению людей из Xamarin.Forms. Вы говорите, что мы должны игнорировать конкуренцию. Действительно?

Что ж, нам лучше иметь страницу " Xamarin для разработчиков Flutter "!

РЖУ НЕ МОГУ. Представьте себе страницу, посвященную «Windows Forms для разработчиков WPF».

XAML - это просто «инструмент» поверх объектной модели ... Вы можете использовать xaml, c #. Вы можете спроектировать свое приложение, используя MVVM (с XAML или без него) или с MVU (честно говоря, предоставленные примеры не были «настоящими» MVU, но это уже другая тема).

Если вам не нравится кодированный пользовательский интерфейс или подход MVU, просто игнорируйте его :) Нет необходимости возвращать его обратно.

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

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

@GiampaoloGabba
Думаю, я должен прояснить, что я меньше против MVU, чем Coded-UI. Меня смущает тот пост, что я боюсь, что Coded-UI станет способом разработки пользовательских интерфейсов по умолчанию (.... я боюсь потерять XAML).

Ну, у нас есть .designer.cs , но нам не нужно было редактировать там код, даже я думаю, что многие разработчики Windows Forms даже не видели содержимое файлов .designer.cs . Но здесь у нас есть _capable_ GUI Editor , и нам не нужно беспокоиться о коде Coded-UI в файле _.designer.cs_.

Я лучше отредактирую заголовок этого выпуска.

Что я хотел сказать:

Что мы выберем между Flutter / Swift / Coded-UI и WPF / XAML с графическим редактором, таким как Blend для Visual Studio ?

@ sim756

Я знаю. Иногда мы пишем new Button () {....}

Иногда люди пишут целые XF-приложения, не касаясь XAML - и им это нравится ;-).

@ sim756

Я знаю. Иногда мы пишем new Button () {....}

Иногда люди пишут целые XF-приложения, не касаясь XAML - и им это нравится ;-).

@aspnetde

Я удивлен..!! 😢

Однако не для них, а для людей вроде меня, которые хотят Blend для Xamarin / MAUI, недовольны:

Редактор движения Android Studio

https://developer.android.com/studio/write/motion-editor

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

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

Что ж, у нас есть .designer.cs, но нам не нужно было там редактировать код, даже я думаю, что многие разработчики Windows Forms даже не видели содержимое файлов .designer.cs.

@ sim756 - в то время как способный дизайнер звучит как отличный инструмент для

Когда дело доходит до XAML, @dsyme говорит об использовании тяжелых инструментов в своем выступлении о Fabulous с разделом, посвященным «Проблема с XAML». Несмотря на то, что у Fabulous много собственных проблем, все же трудно не согласиться со многими из поднятых вопросов.