Flutter에는 Xamarin.Forms에서 사람들을 끌어들이는 데 전념하는 전체 페이지 가 있습니다. 당신은 우리가 경쟁을 무시해야 한다고 말하고 있습니다. 진짜?

블레이저 바인딩이 예뻐요! 저는 이제 막 시작했으며 Flutter가 제공하는 단순성을 제공합니다.

@davidortinau 다른 스레드에서 말했듯이. MAUI 블로그 게시물은 엄청난 혼란을 야기했습니다. 사람들은 이제 MVU = 코드/DSL로 보기라고 생각하는 것 같습니다.
그러나 이것은 MVU가 무엇인지와 완전히 독립적입니다. MVU는 XAML로 완벽하게 가능합니다. 뷰를 작성하는 방법과 관련이 없습니다.
모델과 메시지를 받아 새 모델을 빌드하는 불변 모델 + 업데이트 기능과 모델을 직접 변경하지 않고 업데이트 루프에 새 명령(메시지)을 보내는 뷰 기능을 만드는 것에 관한 것입니다.

MAUI는 UI를 디자인하는 한 가지 방법, 즉 XAML 만 고수해야 한다고 생각합니다.

Blazor Syntex 는 괜찮지만 MVU는 나에게 완전히 불필요한 혼란으로 보입니다. Flutter 개발자를 끌어들이기 위한 것이라면 Flutter를 계속 사용하게 해주세요. XAML의 아름다움을 파괴하지 마십시오.

C# 및 .NET 개발자를 위한 것입니다.

@sim756

MAUI는 UI를 디자인하는 한 가지 방법, 즉 XAML만 고수해야 한다고 생각합니다.

단 한 가지 방법만 있었던 적이 없습니다. 코드 기반 UI는 처음부터 Xamarin.Forms를 통해 지원되었습니다. 접근하기 쉽게 만드는 것이 합리적입니다. 그런데 MVU는 XAML( Xamarin.Forms , WPF )에서 쉽게 사용할 수 있습니다.

@Happypig375

Flutter에는 Xamarin.Forms에서 사람들을 끌어들이는 데 전념하는 전체 페이지 가 있습니다. 당신은 우리가 경쟁을 무시해야 한다고 말하고 있습니다. 진짜?

글쎄, 우리는 " Flutter 개발자를 위한 Xamarin " 페이지

@rohanbojja

블레이저 바인딩이 예뻐요! 저는 이제 막 시작했으며 Flutter가 제공하는 단순성을 제공합니다.

이것만 빼고는 다 괜찮습니다. 그리고 _ 이것이 Flutter를 싫어하는 이유입니다.

이미지 0

@forki

@davidortinau 다른 스레드에서 말했듯이. MAUI 블로그 게시물은 엄청난 혼란을 야기했습니다. 사람들은 이제 MVU = 코드/DSL로 보기라고 생각하는 것 같습니다.
그러나 이것은 MVU가 무엇인지와 완전히 독립적입니다. MVU는 XAML로 완벽하게 가능합니다. 뷰를 작성하는 방법과 관련이 없습니다.
모델과 메시지를 받아 새 모델을 빌드하는 불변 모델 + 업데이트 기능과 모델을 직접 변경하지 않고 업데이트 루프에 새 명령(메시지)을 보내는 뷰 기능을 만드는 것에 관한 것입니다.

정말 혼란스러워요!! 감사합니다. 게시물이 치명적으로 혼란스럽습니다.

이미지 1

@saint4eva

MAUI는 UI를 디자인하는 한 가지 방법, 즉 XAML 만 고수해야 한다고 생각합니다.
Blazor Syntex 는 괜찮지만 MVU는 나에게 완전히 불필요한 혼란으로 보입니다. Flutter 개발자를 끌어들이기 위한 것이라면 Flutter를 계속 사용하게 해주세요. XAML의 아름다움을 파괴하지 마십시오.

C# 및 .NET 개발자를 위한 것입니다.

" C# 및 .NET 개발자를 위한 것입니다. ", 정확히는 Flutter의 영향을 받지 않아야 합니다.

@aspnetde

@sim756

MAUI는 UI를 디자인하는 한 가지 방법, 즉 XAML만 고수해야 한다고 생각합니다.

단 한 가지 방법만 있었던 적이 없습니다. 코드 기반 UI는 처음부터 Xamarin.Forms를 통해 지원되었습니다. 접근하기 쉽게 만드는 것이 합리적입니다. 그런데 MVU는 XAML( Xamarin.Forms , WPF )에서 쉽게 사용할 수 있습니다.

알아요. 때때로 우리는 new Button() { .... } 쓰지만 이 게시물 ( 이미지 1 )은 저와 다른 많은 사람들을 혼란스럽게 했습니다.

@Happypig375

Flutter에는 Xamarin.Forms에서 사람들을 끌어들이는 데 전념하는 전체 페이지 가 있습니다. 당신은 우리가 경쟁을 무시해야 한다고 말하고 있습니다. 진짜?

글쎄, 우리는 " Flutter 개발자를 위한 Xamarin " 페이지

ㅋ ㅋ ㅋ. "WPF 개발자를 위한 Windows Forms" 전용 페이지를 상상해 보십시오.

XAML은 개체 모델 위에 있는 "도구"일 뿐입니다. xaml, C#을 사용할 수 있습니다. MVVM(XAML 포함 또는 미포함) 또는 MVU(공평하게 제공되는 예제는 "실제" MVU가 아니지만 이것은 또 다른 주제임)를 사용하여 앱을 설계할 수 있습니다.

코딩된 UI나 MVU 접근 방식이 마음에 들지 않으면 그냥 무시하세요. :) 다시 밀어넣을 필요가 없습니다.

나는 이것이 단지 플러터 개발자를 유치하기 위한 것이라고 생각하지 않습니다. MVU 패턴은 증가하고 있으며 모바일 개발에 매우 ​​적합합니다.

또한 코딩된 UI가 증가하고 있습니다... react, flutter, swiftUI, ecc... 그들은 많은 인기를 얻고 있으며 과대 광고일 뿐만 아니라... 코딩된 UI는 올바르게 수행되면 큰 혜택을 받습니다.

@GiampaoloGabba
나는 내가 Coded-UI보다 MVU에 덜 반대한다는 것을 분명히 해야 한다고 생각합니다. 나는 Coded-UI가 UI를 개발하는 기본 방법이 될까봐 두렵다는 그 게시물에 혼란스러워합니다(....XAML을 잃을까 두렵습니다).

글쎄, 우리는 .designer.cs 를 가지고 있지만 거기에서 코드를 편집할 필요가 없었습니다. 심지어 많은 Windows Forms 개발자들이 .designer.cs 파일의 내용조차 본 적이 없다고 생각합니다. 하지만 여기에는 _.designer.cs_ 파일의 Coded-UI 코드에 대해 걱정할 필요가 없는 _capable_ GUI 편집기 가 있습니다.

이 문제의 제목을 편집하는 것이 좋습니다.

내가 말하고 싶었던 것:

Blend for Visual Studio 와 같은 GUI 편집기를 사용하여 Flutter/Swift/Coded-UI 와 WPF/XAML 중에서 무엇을 선택할까요?

@sim756

알아요. 때때로 우리는 new Button() { .... }

때때로 사람들은 XAML을 건드리지 않고 전체 XF 앱을 작성합니다. 그리고 그들은 그것에 대해 만족합니다 ;-).

@sim756

알아요. 때때로 우리는 new Button() { .... }

때때로 사람들은 XAML을 건드리지 않고 전체 XF 앱을 작성합니다. 그리고 그들은 그것에 대해 만족합니다 ;-).

@aspnetde

놀랐어요..!! 😢

그러나 그들에게는 그렇지 않지만 Xamarin/MAUI용 Blend 를 원하는 나와 같은 사람들에게는 불행합니다.

안드로이드 스튜디오 모션 에디터

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

@sim756 핫 리로드가 제대로 작동하는 시스템에서 작업한 후에도 여전히 블렌드 지원을 원하는지 궁금합니다. 일반적으로 사람들은 그것을 많이 선호합니다.

XAML/Blend 배경에서 비롯된 코드의 UI에 대한 초기 생각은 반동이었지만 일단 시도하고 보니 단순히 고려하지 않은 많은 이점이 있었습니다. 지금은 엄청나게 복잡해 보이지만 당시에는 완전히 합리적으로 느껴졌던 것의 필요성을 제거하면서 변환기, 리소스 등과 같은 기능으로 인해 코드 우선 UI를 진정으로 믿게 되었습니다.

글쎄, 우리는 .designer.cs를 가지고 있지만 거기에서 코드를 편집할 필요가 없었습니다. 심지어 많은 Windows Forms 개발자들이 .designer.cs 파일의 내용조차 본 적이 없다고 생각합니다.

@sim756 - 유능한 디자이너가 훌륭한 생산성 도구처럼 들리지만 잠시 동안 주변에 있었다면 디자이너가 손상되어 몇 가지 Visual Studio 버전에서 작동을 멈춘 "레거시" 코드베이스에서 작업했을 수 있습니다. 그리고 .designer.cs의 수천 줄을 손으로 이해하고 편집해야 합니다. 이러한 코드베이스에서 버튼 정렬과 같은 아주 작은 변경을 수행하는 데에도 하루나 이틀이 걸릴 수 있으므로 이러한 모든 생산성 이점은 다시 고려됩니다. (이전에 WinForms와 WebForms 모두에 대한 경험이 있습니다).

XAML과 관련하여 @dsym 은 "XAML 문제" 전용 섹션과 함께 Fabulous 에 대해 이야기 합니다. Fabulous는 자체적으로 많은 문제를 가지고 있지만 여전히 제기되는 많은 요점에 동의하기 어렵습니다.